DOCUMENT RESUME 



ED 357 369 

AUTHOR 
TITLE 



INSTITUTION 

REPORT NO 
PUB DATE 
NOTE 

AVAILABLE FROM 



PUB TYPE 

EDRS PRICE 
DESCRIPTORS 



IDENTIFIERS 



CS 213 824 

LeBlanc, Paul J. 

Writing Teachers Writing Software: Creating Our Place 
in the Electronic Age. Advances in Computers and 
Composition on Studies Series. 

Michigan Technological Univ., Houghton.; National 
Council of Teachers of English, Urbana, 111. 
ISBN-0-8141-5911-7 
93 

205p.; Foreword by Hugh L. Burns. 
National Council of Teachers of English, 1111 W. 
Kenyon Rd. , Urbana, IL 61801-1096 (Stock No. 
59117-3050: $10.95 members, $24.95 nonmembers) . 
Reports - Descriptive (141) 

MF01/PC09 Plus Postage. 

^Computer Assisted Instruction; Computer Literacy; 
'''Computer Software Development; English Instruction; 
Higher Education; *Writing (Composition); ^Writing 
Instruction; Writing Teachers 
Computer Interfacing; Writing Contexts 



ABSTRACT 
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To some things we by art must needs attain, 
Others by destiny or luck we gain. 

— Agathon, cited by Aristotle, Rhetoric 

For years, the charge for the computer-assisted composition 
community has been to envision state-of-the-future educational 
technologies. But did we really know the full significance of 
what we were about as a community? Most likely we still do 
not realize how fast the world is changing. These are the best 
of quantum times; these are the worst of quantum times. 

If we thought about how wonderful it would be to provide 
all schools with a literacy infrastructure upon which to build 
successful learners, thinkers, and writers, it was accidental. If 
we wondered how universal connectivity and communication 
would mean nothing if learners were not equipped well enough 
to be able to write or read, it was in those long daydreams in 
our private, computerized inner sanctums, when we were one 
with the code. 

We may not have always realized that the software we were 
developing would empower students who would need, in their 
lifetimes, the ability to seek out and retrieve information from 
any source in the global village. Today, our writers have the 
capability to link up with other writers who are working on 
similar projects, either across the hallway or across the globe. 
They have the capability to write in a community of writers 
from other countries, only satellite-seconds away. Carpe tech- 
nologia. 

Paul LeBlanc's romantic quest makes us all seem smarter than 
we were. At least, this is how I felt as Paul told me of his 
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wanderings to meet many of you — his friends, all. Here is the 
most definitive "who's who" in the development of computer- 
assisted composition over the past fifteen years. Just at the 
moment when computers and composition studies are gaining 
more and more popularity and scholarly respect, here comes a 
scholar who is interested in examining and telling the story so 
that software developers and teachers of composition can begin 
to remember. 

Here are the powerful patterns and portraits. These are the 
roots of rhythm in computers, technology, and composition. 
When Paul asked me to write a foreword for his excursion into 
the world of software development in composition and the craft 
of technology-assisted writing, I was curious how his journey 
would turn out. Now, I know. 

Before reading, I would prescribe a dose or two of self- 
examination. How have you been developing software? How 
will you develop software in the future? What barriers have you 
overcome to marry technology and the humanities? Why is it 
important that composition teachers have a view or an appre- 
ciation of software development? Who designs composition 
software? What trends are emerging in composition software? 
How can faculty participate in the design and the development 
of software for composition studies? What are your own models 
for software development? Can you personally afford or risk 
tenure in your department? What are the implications for the 
field of composition and computers? Such an honest self-inven- 
tory will better prepare you for a conclusion of connections. 
LeBlanc will tell you in the end how computer technology "relies 
on the diminution of its physical presence and is mostly expe- 
rienced through software, which is created through intellectual 
endeavor and imagination — the currency of academic life." He 
is right! "We thus have a rare opportunity," he concludes, "to 
play a part in our own destiny, to help shape the revolution." 
The vision is one we must share, as Aristotle recalled Agathon's 
words: "To some things we by art must needs attain / Others 
by destiny or luck we gain." In software development, art is 
better than luck. 

The several, revolutionary agendas in this book are grounded 
in the pursuit of knowledge — for computer technology has a 
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nasty, consistent habit of providing us only enough knowledge 
to realize what we could be doing with even more technology. 
The biggest misconception in the arena of current design and 
development is that we develop finished products. Software 
does not allow itself to be finished. Software is never finished. 
That is why software is soft I like to think that many of the 
people featured here have visions dancing in their heads — about 
teaching with technology as well as a sometimes unexplainable 
motivation for building tools for composing, when, in fact, they 
know better. They know their current tools vill not fulfill their 
future instructional potentials. But they clso realize that this is 
the only road. Happily, others are on the journey as well, 
although we have not had to worry about a gridlock of scholars. 

Let me present three goals for bringing technology into any 
educational environment and for developing software for com- 
position. What do we want writers and learners to be able to 
accomplish? 

• To use technology to perform some tasks, such as writing 
a pap 9 sending a message, responding to an audience. 

• To learn about and understand technology, such as how 
desktop publishing works or how to write the software that 
implements a grammar-checking program. 

• To employ the technology to support instructional goals, 
such as the use of an integrated writing environment to 
teach composition in a local-area network classroom. 

In tight fiscal times, developers have also had to deal with 
issues of cost and availability, but the software developers 
featured here have identified and prioritized educational system 
needs with a potential for cost-effective resolution through 
technological innovations. Reaching the three goals of technol- 
ogy — using, learning, and employing — must inform all aspects 
of our computer-assisted composition designs. 

What are the strategies for reaching these goalr' Strategies 
should be designed for students, teachers, and communities by 
students, teachers, and communities. Here are some to consider: 

• First, teach how to learn in today's information society — 
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the key objective of education. Computers are the new 
medium of knowledge. Through readily accessible computer 
networks, students can use the electronic libraries of the 
future. 

• Second, achieve instructional gains through the application 
of technology. The benefits of one-on-one instruction are 
supported by the research. A composition teacher's role 
increases significantly as facilitator, coach, and mentor, as a 
result of increased teaching time. Collaborative learning and 
writing environments on local area networks are enabling 
dramatic increases in class participation, by empowering 
students to become aware of very real audiences — them- 
selves. 

• Third, create a global focus through enhanced technological 
capabilities. Use of technology brings the world into the 
classroom, breaking down barriers of ethnocentricity and 
prejudice. Technologies will support distance learning and 
teleconferencing, providing a means of connecting students 
and writers across geographical, political, and cultural 
boundaries. 

Developers have had in mind an insertion of technology into 
the learning environment which emphasizes technology's ability 
to help improve the teacher-to-student ratio, making one-on- 
one instruction and team collaboration the standard approaches 
to teaching and learning. This is strategically possible. 

Let me offer a brief reflection on the possible and the impos- 
sible. In Book II, Chapter 19 of the Rhetoric, Aristotle speaks of 
the "Possible and Impossible." He argues that, "If it is possible 
for one of a pair of contraries to be or happen, then it is possible 
for the other" (1392a, 9-10). He illustrates: 

That if a thing can come into being in a good and beautiful 
form, then it can come into existence generally; thus a 
house can exist more easily than a beautiful house. That if 
the beginning of a thing can occur, so can the end; for 
nothing impossible occurs or begins to occur. . . . That if the 
end is possible, so too is the beginning. 

Beginnings have compelled the many software developers you 
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will meet in the following chapters. Our computer-assisted 
composition programs have come into being generally, but their 
goodness and their beauty have yet to be truly achieved. That 
is what we've begun — and if the beginning of a thing can occur, 
so too can the end. 

If LeBlanc has written of past facts, how should we be 
encouraged to address questions of the future? How should they 
be argued? Aristotle would have us consider: 

That a thing will be done if there is both the power and 
the wish to do it; or if along with the power to do it, there 
is a craving for the result, or anger, or calculation, prompting 
it. (1392a, 1-3). 

If there is a foundation, there will be a house. LeBlanc's notions 
about computers and writing "redesign" are worth examining 
in detail. Are we in an age of evolution or revolution in design? 
These stories illustrate the power and the wish to change the 
way technology works for us in our composition courses. There 
continues to be a craving for tools that will empower each 
individual writer. These teacher-developers are angry about the 
massive illiteracy. Many have had to resort to political calculation 
to make their technologically enriched learning places exist. But 
now there is a foundation. Their mantra: Develop it and they 
will come. 

If these are the stories of how we begin to remember, then 
what are the lessons for future developers? Here are three I find 
most promising; you will find others throughout this book: 

• Specify a bold technology-support infrastructure. Consider 
the complete set of information/communication systems 
technologies such as availability of computers, use and need 
for local-area networks, availability of word-processing soft- 
ware, extent of satellite and wide-area networks, even 
television and radio studios, etc. Then design software that 
will allow access to shared resources with other writers, 
developers, teachers, schools, communities, and countries. 

• Design for overall technology awareness. Develop software 
that enable individuals to achieve the literacies we will need 
in the twenty-first century. Especially within the school's 
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own community, provide role models who are working in 
and developing the technologies, and acquaint students with 
common technologies for the new communication age (e.g., 
networks, common software applications, FAX machines, 
photocopiers, CD players, video technologies, laser discs, 
and so on, through hands-on experience). 

• Solicit community support and real audiences for computer- 
assisted writers. For example, writing about a judicial process 
is best done where the action is. Identify places where 
situated learning and writing experiences are appropriate 
and best handled in the real world — then connect. 

My hope is that tools such as those dreamt of by the developers 
in this book will provide avenues for global literacies and 
universal understandings. If I am disturbed about the future, it 
is because we may not be able to develop their ideas fast enough 
to keep pace with the changes in hardware. The gap we 
experience between just being and just becoming will continue 
to broaden. These are the evolutions in design and development 
of computer-assisted composition, and they are to be expected 
and somehow compensated for. 

This book reflects and reidndles many memories. Software 
development finally boils down to a list of qualities you want 
to see developed in people. As a teacher, you will not have time 
to do it all, to do it one-on-one, to do it with swank and gusto 
and enthusiasm and guts. In my case, I still want to have writers 
talk about "idea" as a plurality — a great chain of associations, 
memories, experiences, knowledge, and information. Technology 
allowed me to get there. We can all build such unique foundations 
for our writers. 

Can you remember the first time you allowed your students 
to work on a computer in the writing workshop? Were you like 
me at first, trying to pry into their writing zone and help? When 
were you brave enough to leave the room and look back in 
through a window — wondering if the software you had devel- 
oped was powerful enough to be useful? Are you part of the 
generation that helped switchboard operators listen to the high- 
pitched sounds of mainframe computers yearning to be called? 
Are you part of the generation who told colleagues the differences 
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between hardware and software, bits and bytes, word processing 
and data processing, hypertension and hypermedia? Can you 
remember when your composition students began enjoying the 
composition of an essay, even laughing aloud at different times 
while writing? Have you noticed, in these settings, how you 
have provided a place and pace for writing and thinking that 
honors each student's learning and writing styles? Do you have 
college-age children who come home at Christmas break and 
blurt out with excitement, "You would really like the literature 
class I'm taking. It's cool. We write all at once on a local-area 
network. Then we share the transcripts!" 
Yes, software development is cool. 

Yes, we have been and are a community of possibilities. "Good 
enough" is no longer plausible. Intrepid development. Relentless 
patience. Whoever thought that electrons and microchips could 
be such good friends to humanists? 

Yes, this is a book about the importance of connecting. 

Yes, these are the stories of how we begin to remember the 
evolution. 

Yes, these are the roots and rhythms of the quiet revolution 
of technology in our composition classrooms. 
Yes. Thank you, Paul. 

Hugh L. Burns 
San Antonio, Texas 
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Chapter 1 



Introduction 



There is a trap in talking about writing and computers. The 
trap is to consider writing as a "natural" activity and the computer 
as a technology that merely serves it. The fallacy asserts that 
writing is writing, whether it be done with pencil, pen, typewriter, 
or computer — the intellectual act of composing remaining fun- 
damentally unchanged by the various composing tools we pos- 
sess. However, as Walter Ong (1982) points out, writing is itself 
a technology, one that initiated "the reduction of dynamic sound 
to quiescent space, the separation of the word from the living 
present, where alone spoken words can exist" (p. 82). The 
movement from orality to literacy was driven by the adoption 
of a new technology — writing — a technology no more natural 
or fixed than any other. Now, with the rapid proliferation of the 
microcomputer, the technology we know as writing is itself 
undergoing a transformation, the scope of which might be as 
important and far-reaching as the earlier shift from spoken to 
written communication. As Ellen McDaniel (1987) says, in dis- 
cussing composition software: 

The truly substantial influences of printing, like those of 
writing, were long in developing but ultimately affected 
human thought, learning, and expression — the text-maker 
and the making, not simply the text itself. Now, technology's 
effect on literacy concerns us again as we inspect the densest 
technology yet to come between idea and expression, imag- 
ination and form, thinker and composer, (p. 139) 

In other words, writing is being redesigned by the computer in 
much the same way that the Gutenberg press was said to have 
redesigned it, with similarly profound implications (Eisenstein, 
1979). 

As Ong (1982) argues, technologies effect "interior transfor- 
mations of consciousness, and never more than when they affect 
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the word" (p. 82). When individuals adopt a new tool for 
writing, they may very well be adopting a new way of thinking 
about writing, and even a new way of thinking, generally. This 
is not a new idea. Consider Quintilian's advice to his students 
in the first-century Institutio Oratoria: 

It is best to write on wax, owing to the facility which it 
offers for erasure, though weak sight may make it desirable 
to employ parchment by preference. The latter, however, 
although of assistance to the eye, delays the hand and 
interrupts the stream of thought, owing to the frequency 
with which the pen has to be supplied with ink. (Graves, 
1984, p. 226) 

Our writing tools have always mattered in the way we compose. 
Technological determinists such as Havelock, Eisenstein, Mc- 
Luhan, and Ong have illustrated the power of technology to 
reshape the nature of knowledge and knowledge making. 

On the other hand, Nancy Kaplan (1991a) points out that 
technological determinism can fail to recognize the matrix of 
social, economic, and ideological forces within which technol- 
ogies arise, are shaped, and then distributed: 

Tools of inscription embody and construct ideological prac- 
tices, redefining what exists, what is good, and what is 
possible to do. But understanding the opportunities and 
transformations that the tools themselves may offer cannot 
ful'y explain or predict their effects on the world. Technol- 
ogies, after all, arise out of and operate within already 
existing social, political, and economic relations, (p. 21) 

She reminds us that the relationship between technology, with 
its power to shape culture and society, and society itself and its 
ideologies, within which technologies are themselves shaped, is 
a recursive one. We are simultaneously the shapers and the 
shaped, proactive and reactive. As teachers and researchers of 
writing, we need to be as sensitive to the development and 
implementation of writing technologies as was Quintilian; as a 
field we need to pay much closer attention to, and assert our 
role in, the development and widespread adoption of the mi- 
crocomputer as the primary tool for writing in the next millen- 
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nium. Doing so allows us and our students to be users of 
technology rather than its victims. 



Technology Takes Hold 

While precomputer writing technologies developed slowly, 
their impact occurring over a long period of time, computers 
have invaded the classroom, workplace, and home with dizzying 
speed. Just four years after the commercial introduction of the 
microcomputer, computer-based learning programs were in use 
in 50 percent of U.S. educational institutions (Chambers and 
Lewis, 1988, p. 31). According to the Second National Survey 
of Instructional Uses of School Computers, in the two-year 
period from 1983 to 1985, the number of computers used in 
elementary and secondary schools quadrupled from 250,000 to 
over one million. During that same period, the number of schools 
introducing computers into the curriculum tripled (Herrmann, 
1989, p. 111). Over 95 percent of all public schools now have 
computers, and the ratio of students to computers continues to 
close from 92 to 1 in 1983, to a current ratio of about 26 to 1 
(COTA 31-4). Fortune 500 companies are already predicting 
"saturation": one computer per white-collar employee (Debs, 
1988, p. 5). And a recent poll revealed that 25 percent of 
American households now own personal computers and that 70 
percent of those computers are being used for schoolwork (Lewis, 
1992, p. 48). In educational and work settings, and increasingly 
at home, the number one use of the microcomputer continues 
to be for writing. As Charles Moran (1991) asserts, "Computers 
are here; very few writers would return to the old ways, even 
if they could do so. Because computers are here, we can't not 
teach student writers in on-line environments" (p. 1). 

Software programs designed or appropriated for writing in 
an on-line environment have, appropriately, seen a correspond- 
ing increase in number and sophistication. Simple word-pro- 
cessing programs, their roots in the rudimentary line editors of 
programming software, have evolved into complex programs 
that can include spelling, grammar, and style checkers; on-line 
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handbooks; desktop publishing features; and electronic m?il 
capabilities. These programs often have windowing capabilities 
that allow work on multiple documents, electronic note taking, 
and easy movement between word processing and other types 
of programs such as database or graphics software. Comple- 
mentary programs to aid in writing — such as invention, peer 
editing, instructor feedback, and outlining programs — are widely 
available. Moreover, as we struggle to understand the effects of 
these innovations, at the same time, we see breakthrough 
developments occurring in hypertext and hypermedia which 
allow the creation of multimedia documents that link text, video, 
graphics, and sound in multiple, nonlinear ways. Networking, 
telecommunications, and large database storage media are pro- 
viding writers vith new, powerful possibilities for collaboration 
and immediate access to vast amounts of information. 

As specialists in writing, in the production and study of texts, 
we, as a field, must come to grips with the profound changes 
in written communication which are taking place because of the 
adoption of the microcomputer as a writing tool. Increasingly, 
we are able to discern the characteristics of the emerging literacy, 
Andrea Lunsford, in a paper presented at the 1991 MLA con- 
vention, indicates some of these changes: 

In speaking of electronic literacies, I take it as a given that 
print literacy — the traditional technologies of reading and 
writing — is in the process of being transformed into a literacy 
or set of literacies in which text is never fixed or definitive; 
in which authors are not single authorities (much less stable 
selves), but always polyvocal; in which "reader" and "writer" 
as well as "creator" and "critic" regularly merge; in which 
intellectual property as we have known and defined it is 
challenged and exclusionary "ownership" impossible; and 
in which new zrts and genres will emerge, (p, 4) 

While we remain in the transition period between traditional 
print literacy and electronic literacy, the speed of that transition, 
if the last ten years are any indication, will be infinitely faster 
than the hundreds of years that attended the movement from 
oral to written literacy. 
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Of Teachers and Their Tools 

Anyone working in composition today must pay at least 
nodding acceptance to the impact of electronic technology — and 
ironically, even the most recalcitrant are probably working on 
computers. That has always been the implicit (and often explicit) 
message of journals like Computers and Composition and confer- 
ences such as the annual Computers and Writing Conference. 
That message has been increasingly echoed elsewhere. Alan 
McKenzie (1991), for example, urges humanist scholars to get 
on-line in the MLA's Profession 91. Lunsford (1991) stressed this 
point in her MLA address: 

Video and electronic literacy will affect the way we think 
about and act in the world. I also believe, however, that it 
is up to us to help decide exactly how these new literacies 
will affect us. Yet our community has, by and large, refused 
to accept this responsibility for literacy, leaving it instead to 
those who want to use electronic literacies for their own 
ends — primarily business, entertainment, and military pur- 
poses, (p. 5) 

The need for composition and English studies to play a powerful 
role in the shaping of electronic literacy is the underlying 
argument of this book. 

The Emergence of Computers and Writing Studies 

For more than ten years, a small but growing number of 
composition researchers and teachers have been attempting to 
assert their role in shaping electronic literacy. As computers 
found widespread use in college and university writing programs 
in the 1980s, composition specialists began studying the rela- 
tionship between writing and technology. My work, for example, 
had its roots in my experience as a teacher of writing in a new 
computer-supported environment. My interest was first sparked 
by something which I had not seen before in my writing classes: 
students rushing into the lab, a full ten minutes before the 
scheduled starting time, and lingering on after class until the 
next eager ? Ludents forced them to vacate their work sessions. 
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Before almost anyone conducted research on the effects of 
computers on the writing process, everyone working with com- 
puters knew one thing: most students are highly motivated to 
write with computers, good effects or not. Computer- Aided 
Composition (CAC) instructors like me began to watch more 
closely the writing behaviors that took place in our computer 
classrooms, and we began to publish our results in the new 
computer and writing journals that began to spring up. 

In retrospect, those of us who were interested in CAC were 
looking at tools that were new, powerful, and continually evolv- 
ing. As Gail Hawisher (1989) noted, our research reflected the 
confusion and contradictions of an emerging field (p. 64). Take, 
for example, the contradictory research on the quality of revision 
when performed on a computer. Burnett (1984), Dalton and 
Hannafin (1987), Howard Kaplan (1986), Moore (1987), and 
others argued that the quality of student revision is better when 
performed on a computer. However, Beesley (1986), Coulter 
(1986), Duling (1985), Woolley (1985), and others disagreed. 
Some, such as Cirello (1986), Daiute (1985), and Haas and Hayes 
(1986) reported mixed results. And yet others, myself included, 
argued that a writer's predisposition toward revision influences 
the quality of that revision much more than the computer 
(LeBlanc, 1988; Hawisher, 1989). Yet, underlying this small but 
growing body of research was a sense that we were all working 
with a tool that, when widely adopted, might have a dominant 
influence on our concepts of text and text production. 

Faculty-Based Software Development in Composition 

While those cited above were reacting to their students' use 
of computers for writing, other, perhaps braver, souls were 
working to make the tool their own. They were the first com- 
position teachers and researchers to design and develop their 
own software. Their numbers included Hugh Burns, who, as a 
graduate student at the University of Texas at Austin, wrote an 
invention program based on Aristotle's topoi, Burke's pentad, 
Young, Becker, and Pike's tagmemics. James Strickland wanted 
a computer program that would enact some of Peter Elbow's 
prewriting strategies, found none, and then wrote FREE in 1982. 
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Others, scattered about the country, were also engaged in pro- 
ducing composition software. Their efforts often went unnoticed 
and unrewarded by their institutions, but they pointed to the 
one area where the field can actively shape the tools it uses, 
and thus shape the conception of writing implicit in those tools — 
the design of software. 

The focus of this book is faculty development of software for 
composition studies. It attempts to describe who is building 
these writing tools, how they are doing so, how their work is 
being received, and what is likely to affect their efforts in the 
future. The discussion, however, does not include a survey of 
current computer writing programs. While such a survey would 
be useful, it would not clarify the future of faculty-based software 
development, for the pace of technological change almost always 
makes a close look at the present an immediately outdated 
perspective. There is also little discussion of hardware, a reflection 
of both the minor role writers' needs have played in hardware 
development and the fact that hardware development is beyond 
the reach of even the best-funded and most expert computer 
and writing specialists. However, these conditions are not true 
for software. 

We may have to live with the hardware produced by Apple, 
IBM, and other corporate manufacturers; software, however, can 
be written with far fewer resources. Moreover, it is software that 
gives hardware its final shape, in the sense that software defines 
how hardware is used. It is software, for example, that makes 
a computer network a tool for collaboration or a tool for control 
and exertion of authority. This is what that small ni mber of 
faculty software developers have always realized. Finding no 
published studies of their work, I set out to talk with them about 
the development of CAC software. 

My discussions with faculty software developers confirmed 
an early notion that how a tool gets built, and who is building 
that tool, will have important implications for how that tool 
looks and works. The people who build tools, and their methods 
for doing so, have great power to define their use. This is 
particularly true for the computer. The manufacturer of a hammer 
may intend it to be used for building, but it can be used just as 
easily for a weapon. A software designer, on the other hand, 
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knows that the grammar-checking program he or she designs 
can be used for little else. If the designer of a networked 
collaboration program decides not to include a function which 
allows the instructor control of or access to students' screens, 
that designer has limited the use of the network as a social 
control mechanism. 

Collecting Stories 

At the heart of my research is a collection of stories that 
describe the design and development of composition software 
by CAC Jpecialists. Those interviewed ranged from researchers 
working in well-supported, well-staffed university settings, to 
untenured instructors with heavy teaching loads, to academic 
entrepreneurs attempting to combine their teaching and research 
with the commercial sale of their software. In each case, their 
accounts addressed five key areas of inquiry: 

1. Who Designs CAC Software? Who is involved in the devel- 
opment of the software? If more than one person is 
involved, how does the group interact? In group efforts/ 
how are the responsibilities and work delegated, if at all? 

2. How Are Programs Completed within a Development Model? 
For example, does the effort to develop a program start 
with a model of writing behavior? Is there field testing 
during and/or after the development of the program? 

3. What Are the Forces That Impac the Development of CAC 
Software? What are the key technological components of 
software development? How are development projects 
usually funded? What role, if any, do English departments 
play in the development effort? Does marketing influence 
design decisions? 

4. What Trends, if Any, Are Emerging in CAC Software Devel- 
opment? Are new technologies fundamentally altering soft- 
ware development? Are developer profiles changing? Is the 
increasing interest in software shown by publishing houses 
proving supportive or problematic? 

5. What Are the Implications of the Aforementioned Areas of 
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Inquiry for the Field of Composition, Generally? Can we begin 
to see ways in which CAC software might challenge 
accepted beliefs about good writing and writing behaviors? 
Do emerging trends in CAC software development favor 
certain theories of writing over others? What should the 
role of English departments be in supporting the future 
development of software programs? 

While a wide range of models, or approaches, exists for devel- 
oping software, four principal ones emerged from the interviews: 

the Lone Programnv 

the Small Design Group; 

the Entrepreneur; 

the Research-Based Design Team. 

Accounts illustrating each model answer many of the questions 
posed above, suggest strengths and weaknesses in each approach, 
and, taken as a group, offer an overview of the state of software 
development within our profession. 

Moreover, the accounts — with all their drama of people being 
fired for developing software, or staying up late into the night 
working on programs, or winning national recognition— bring 
into sharp focus the larger issues facing English studies and 
composition professionals as we move toward virtual-age literacy. 
In chapter 4, I use the collected accounts to identify what seem 
to be the predominant forces shaping software development 
within composition. Some of these are technical — for example, 
the availability of easy-to-use software authoring programs or 
the impact of object-oriented programming languages. Others 
include the politics of English departments and their attitudes 
toward technology, generally, and computers and writing re- 
search, specifically — for example, the availability of release time 
and the treatment of software development in promotion and 
tenure decisions. Software development is often expensive, and 
the sources of funding for such efforts may also shape the final 
product. Some of these forces seem to encourage the faculty 
development of software; others seem to work against it. 
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If software development is indeed a primary way for com- 
position specialists to help shape the emerging literacy, we, in 
the field, must understand these influencing forces, and in some 
cases, address growing problems related to them. These problems 
are examined in the final chapter of the book, as the scope of 
the discussion widens to encompass the larger changes in literacy 
that are taking place due to the force of technological innovation 
and the role of composition studies in accommodating and 
guiding those changes. 

This work is an attempt to shed light on where we are and 
where we might go in the development of composition software. 
It is an understanding that we lack at present. Composition may 
become more reactive to technology — notice the increasing num- 
ber of related journal articles and conference panels, and the 
job advertisements that include computer and writing experience 
as desired qualifications. By contrast, there continues to be almost 
no discussion of software design within the field, and there are 
alarming indications that the number of faculty software de- 
velopers in composition is declining, thus making us less proac- 
tive in shaping the technology. Such a phenomenon raises 
Lunsford's (1991) key concerns: 

Who will create and control the programs, the networks 
(on which many are, ironically silenced and excluder*), the 
architecture of interactive fiction, the prototypes of virtual 
reality? And who will train not only the creators but the 
interpreters of these electronic literacies? I want to urge that 
the answer to these "who" questions had better include us. 
(p. 6) 

If we wish to take a proactive role in the shaping of electronic 
literacy, software design should be as mainstream an activity for 
composition professionals as teaching a writing class, conducting 
a research study, or writing an article. Otherwise, we risk leaving 
the new electronic literacy in the hands of "IBM, Disney, and 
the U.S. Air Force," as Lunsford warns (p. 5), and relinquishing 
our proper role as central players in shaping the writing spaces 
of the future. ^ 
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When writing teachers want to create textbooks, they begin 
almost immediately by examining the marketplace — what has 
come before and what is out there now. Key elements in any 
textbook prospectus are the author's recognition of the compe- 
tition and her accompanying analysis of how the prospective 
book will allow the publisher to meet that competition head- 
on/ This sensitivity has a basis in market analysis (i.e., the 
number of copies that a text is likely to sell), but it also speaks 
to a tradition in the textbook trade that, in the case of compo- 
sition, stretches back to the nineteenth century and the shift in 
focus from oral to written discourse (Connors, 1986, pp. 186- 
187). The prospective textbook writer might start by walking to 
a shelf and pulling down textbook after textbook, surveying 
what has already been done, discovering the conventions of the 
medium, and so on. The writer might also choose to consult the 
body of critical literature on textbooks, for example, the work 
of Stewart, de Beaugrande, Welch, Connors, and Winterowd. 
Moreover, unlike colleagues in other disciplines, whose training 
may have included much less writing, the writers of composition 
textbooks are themselves likely to be competent writers and feel 
comfortable working with text. 

In contrast, consider the challenges confronting the writing 
teacher who wants to develop software. Computers have only 
seen extensive use in writing instruction for less than a decade. 
While there exist dozens of writing-related software programs, 
their distribution has been spotty and tied to particular hardware 
configurations. These programs have often gone without up- 
dating and no longer run under new operating systems, and 
much of this software is either uninteresting or of poor quality. 
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Reviews of software are often hard to find; in particular, there 
is almost no extant body of critical writing about CAC software 
development. Indeed, one major aim of the present volume is 
to help establish a context in which future software developers 
can situate their efforts. Moreover, those involved with software 
development in recent years report less camaraderie and sharing 
among faculty developers than that which characterized the 
early days of such work (Wresch, 1992, interview; H. Schwartz, 
1992, interview). 

In addition to a lack of tradition or a body of self -reflective 
research, prospective CAC software developers must work either 
directly or indirectly with programming languages in which most 
have had no training. Joseph Bourque (1983) speaks to this 
challenge in one of the earliest articles examining the faculty 
software developer in the humanities: 

In addition to mastery of subject matter and methods, the 
CAI specialist must learn one or more computer languages, 
a time-consuming process ... It often means brushing up 
on math for people who have had most of their education 
in the humanities, and, as programmers know, writing 
programs demands attention to detail. A single period out 
of place can create a "bug" that may take hours to trace, 
(pp. 69-70) 

While newer authoring programs such as HyperCard or ToolBook 
are much easier to master than programming languages such as 
PASCAL or C, the developer still needs to learn a tremendous 
amount of technical material to fully develop any substantial 
application. Also, while not underestimating the importance of 
good textbook design, the CAC software developer must work 
with interface design in a medium for which few English faculty 
are trained and for which there is much less readily available 
help from publishers. Finally, in developing software, there is 
the central challenge of outlining concretely what one believes 
to happen when writers engage in the process of creating text. 

Turning Knowledge into Software 

At the heart of even the most ambitious computer program — 
whether it be a NASA navigational program or, closer to home, 
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John Smith's Writing Environment (WE) — there is the simplest 
on/off action of electronic current. This most essential fact of 
computer operations has a powerful influence on the writing of 
software and the way knowledge is embodied within program- 
ming code. This discussion offers a brief examination of the 
ways in which knowledge is classified and represented in soft- 
ware design, and of the implications that inform how software 
is written. Understanding this connection provides a context for 
this examination and helps explain why some approaches to 
composition are more likely than others to be computationally 
rendered. 

There were, properly speaking, three progenitors of the mod- 
ern digital computer. The idea of the computer was first conceived 
by Charles Babbage, venerable British mathematician and in- 
ventor, in 1833. His "analytical engine" was never built due to, 
what were then, insurmountable engineering problems (Johnson, 
1987, p. 61). Just over one hundred years later, in 1936, English 
mathematician and logician Alan M. Turing (1937) set out to 
prove some esoteric results in symbolic logic and wrote one of 
the most innovative, yet little-known, documents of the twentieth 
century: "On Computable Numbers, with an Application to the 
Entscheidungsproblem." In what Joseph Weizenbaum (1976) has 
called "one of the greatest triumphs of the human intellect," 
Turing laid out the theoretical foundation for all digital computers 
up to the present time, showing how to build one a full decade 
before his design would actually be realized in working form 
(p. 58). It was left to John Van Neumann to build the first 
computer and to set up its basic design configuration. 

Like so many machines of our age, the computer does not 
convey physical power — it has almost no moving mechanical 
parts. The computer redefined the term machine to include those 
devices which are transformers of "information," usually through 
electronic impulse. The distributor of the modern automobile 
ignition system, a mechanical configuration of gears, a shaft, 
and cams, which timed the firing of spark plugs, has been 
largely replaced with the nonmechanical "control module" or 
"on-board computer," which consists of silicon chips controlling 
electronic impulses to the spark plugs as well as controlling a 
host of other functions. Those electronic impulses, traveling at 
the speed o/ light, represent and convey information. 
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The representation and processing of information in the form 
of electronic impulse is simply more difficult to do for some 
kinds of information, because it demands a descriptive precision 
that is not always so available. We can describe precisely, for 
example, the cognitive steps in determining the square root of 
a number, but who would purport to know precisely the steps 
that lead to a poem, a short story, or a freshman essay? 

Procedural Knowledge 

Weizenbaum (1976) asserts that if we understand a phenom- 
enon in all its behavioral rules, we can express it in the form 
of a computer program. To understand and program a phenom- 
enon, one must break it down into its smallest parts, or in the 
parlance of programming, its procedures. A set of procedures is 
called an algorithm. The set of procedures for finding out if a 
number is prime, for example, is pretty straightforward and 
might be mapped out like this: 

1. Determine the number to be tested (computer user gives 
the information). 

2. Call that number A. 

3. Set the number to divide by, X, equal to 2. 

4. Divide A by X. 

5. If there is no remainder, go to step 8. Otherwise proceed 
to the next step. 

6. Add 1 to X. 

7. Is X now equal to A? If so, go to step 9; otherwise return 
to step 4 and repeat the loop. 

8. Print "The number is not prime' 7 and end. 

9. Print "The number is prime" and end. Oohnson, 1987, p. 
84) 

The activity of finding prime numbers is logical and mathematical 
from the start. Writing a simple word-processing program is 
relatively easy, since text use has prescribed rules that the 
programmer can follow. 
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For phenomena which are not wholly or inherently rule- 
bound — the activity of writing, and much of life, for example — 
the task becomes much more difficult. If we were to attempt to 
write a program that could diagnose even a fairly limited 
problem, such as a car not starting, we would have a terrific 
challenge setting out the procedures involved. We would be 
facing what has become known as the "knowledge-acquisition 
bottleneck" (Johnson, 1987, p. 164), We could prioritize a list of 
problem-solving questions which the user could answer and for 
which she could write appropriate algorithms: "Is charge in 
battery 12 volts? If yes, proceed to the next question. Are the 
battery terminal leads securely fastened to the terminals? If no, 
tighten the leads. If yes, proceed to the next question" (and so 
on). But how do we program a mechanic's years of experience 
(e.g., "The points are always closing up on that year of VW 
Beetle") or intuition (e.g., 'Tm not sure why, but this sounds 
like the fuel pump isn't working")? 

Reducing expert behaviors to procedural steps has been the 
challenge for researchers who work with Intelligent Tutoring 
Systems (ITS), computer programs that teach students what 
experts do when confronted by a given problem. The answer 
to the problem has been "knowledge engineering." Martha 
Poison (Poison & Richardson, 1988) explains: 

A knowledge engineer interviews an expert and designs a 
computational representation for delivering the knowledge, 
usually a rule-based formalism. This implementation does 
not necessarily correspond to the way the human expert 
reasons, especially in novel, unfamiliar situations or when 
providing explanations . . . However, knowledge-engineer- 
ing tools and techniques, that is, ways of extracting and 
codifying information, are becoming more and more useful 
for ITS development as attention is paid toward making 
representations more faithful to the breadth and depth of 
expert reasoning, (p. 4) 

Knowledge engineers, through intensive interviews with many 
experts, attempt to identify the problem-solving strategies which 
those experts employ and which underlie other, more difficult- 
to-identify processes, such as intuition. 

In the example just given — diagnosing an ignition problem 
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in an automobile — one might not be able to produce algorithms 
for intuitive knowledge/ but the general task still lends itself to 
description in procedural terms. Similar tasks have been repre- 
sented successfully in computational form at the Intelligent 
Systems Branch of the Air Force Human Resources Lab, where 
programs walk the user through the diagnosis for a broken- 
down tank or the process for changing the orbit of a satellite. 
In CAC programming, programs that analyze text for grammatical 
"correctness" are examples of such procedural programs. The 
speed and vast memory of the computer help to make up for 
its lack of experience or intuition. 

Declarative Knowledge 

Finding out whether a number is prime or checking on subject- 
verb agreement are considered types of "procedural knowledge." 
A second level of knowledge might be called "declarative 
knowledge," general knowledge about a particular area, for 
example, South American geography. The Scholar project, an 
early attempt to program information about South American 
geography, required an elaborate, semantic net representation of 
the knowledge base involved, one that consisted of various 
nodes which represented a wide range of concepts, such as 
countries, products, capitals, latitudes, forms of government, and 
so on (Carbonell, 1970, pp. 190-202). Programs in the area of 
declarative knowledge have tended to employ Socratic dialogue 
between the program and the user. The key to successful 
programming of declarative knowledge is to firmly establish the 
boundaries of that knowledge area and to keep the user within 
that domain. For example, in the area of CAC programming, 
Confer would be an example of such a program. The program 
interacts with the user in the analysis of a single short story, 
and it focuses entirely on text-based questions and responses — 
a highly defined knowledge base. 

Qualitative Knowledge 

In terms of computational representation, the ability to reduce 
information and procedures to mathematical representation — 
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the most challenging area for programmers and the one most 
relevant to composition studies — is "qualitative knowledge/' tue 
knowledge that allows us to operate in dynamic and changing 
environments. This is the knowledge base that allows us to 
process all of our knowledge to find the best ways to solve a 
problem or to create a piece of art such as a short story or essay. 
Sheldon Klein and his associates have attempted to write this 
type of program, an "automatic novel writer," which produces 
passages such as the following: 

The day was Monday. The pleasant weather was sunny. 
Lady Buxley was in a park. James ran into Lady Buxley. 
James talked with Lady Buxley. Lady Buxley flirted with 
James. James invited Lady Buxley. Lady Buxley was with 
James in a hotel. Lady Buxley was near James. James caressed 
Lady Buxley with passion. James was Lady Buxley's lover. 
Marion following them saw the affair. Marion was jealous. 
(Qtd. in Boden, 1977, p. 300) 

This passage reveals the ability of a programmer like Klein to 
extract from a qualitative knowledge base some system of 
procedural knowledge, which in this case provides what might 
be a skeleton of a murder mystery, but not the knowledge base 
that underlies style and subtlety, and in the instance of a murder 
mystery, surprise. A complex activity like writing clearly draws 
upon procedural, declarative, and qualitative knowledge bases- 
how the mind "processes" that knowledge in the completion of 
the writing task is something about which we know very little. 
Intelligent Tutoring Systems (ITS) experts continue to work on 
the problem of representing all three knowledge bases and their 
interactions. Poison (Poison & Richardson, 1988) says that "one 
of the most challenging issues will be constructing a metatheory 
that unifies and shows the relationships between procedural, 
declarative, and qualitative knowledge" (p. 5). The need in 
programming for a clear mapping out of knowledge operations 
makes cognitive approaches to composition, with the highly 
defined cognitive models offered by researchers like Linda Flower 
and John Hayes, appealing to many who work in CAC pro- 
gramming. In fact, the best-funded and most technically ambi- 
tious CAC projects have been cognitive-based research projects. 
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The alliance of cognitive science and computers is not a new 
one. The close link between cognitive science and computer 
technology forms the basis for the work of composition cogni- 
tivists. In their landmark "Empirical Explorations of the Logic 
Theory Machine: A Case Study in Heuristics," Newell and Simon 
(Newell, Shaw, & Simon, 1957) made an assertion that is the 
basis for a cognitive approach to writing theory: "that pro- 
grammed computer and human problem solver are both species 
belonging to the genus 'Information Processing System"' (Qtd. 
in Weizenbaum, 1976, p. 169). This is a profound declaration 
of equality between computer and human — one that elevates 
the computer, at least in its potentialities, and that abases 
humanity, so that Newell and Simon can even talk of our 
"programmability" (Weizenbaum, 1976, p. 169). While much 
vehement debate has occurred in the field of computer science 
over the validity of Newell and Simon's equating of human and 
machine, the comparison of the two in computer programming 
is hard to avoid. As Bolter (1984) points out: 

Man can solve problems in one way, machines in another. 
But in fact, the analogy remains firm in the minds of 
programmers. Computer programs are open to inspection, 
and human ways of thinking are not. When a programmer 
devises an algorithm for playing chess or for analyzing 
English grammar, he can hardly avoid regarding human 
performance by analogy with his invisible, intelligible al- 
gorithm. As one psychologist has put it, the computer model 
of the mind is the only working model available and even 
a bad model is better than none. (pp. 193-194) 

In a sense, the strength and appeal of Newell and Simon's 
General Problem Solving (GPS) theory is its ability to schematize 
human thought (or its model) in a way that has eluded other 
theorists of cognitive activities. This has, in effect, put the onus 
on humans to think like computers, instead of forcing computers 
to think like humans. 

As teachers of writing who use CAC programs, we need to 
be sensitive to this dynamic. For example, Smith's WE program, 
which will be discussed later in more detail, attempts to aid the 
student writer in all parts of the writing process (as Smith 
understands them) — except for the "social aspects of writing," 
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as he puts it. Why the omission of that important, some might 
say key, area? It is the one area of his model that falls within 
the qualitative knowledge area — as we have seen, the most 
difficilt to program for. The result of its exclusion from the 
program is that students using WE will not address those 
concerns, will be practicing a model of writing, and will pre- 
sumably adopt that model at some cognitive level. The important 
question is to what degree does their thinking start to reflect 
the program and what it is able to do, rather than the inverse. 

Computers are not flexible. That is, either one uses them and 
plays by their rules, or one does not use them. As we have 
seen, the computer is being widely adopted as a tool for writing. 
Anyone debating whether computers are good or bad for us is 
missing the point, for computers and CAC programs are here to 
stay and are quickly becoming universal in the classroom and 
workplace. New CAC programs are being released almost every 
day. This technology — the computer and the software we run 
on it — has the power to redefine not only what we consider 
text, but more importantly, how we mentally produce text. If the 
demands of binary language require knowledge to be reduced 
to precisely defined procedures and algorithms, and if that favors, 
and even in a sense validates, cognitive models of writing, and 
if the CAC programs that are most widely used are cognitively 
based, then our practice and our thinking about writing will 
follow suit. In that very important sense, computer-aided com- 
position has the power to be a defining force in composition 
studies. 
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To put it simply, much of my research was the gathering of 
stories. I grew up in a family of construction workers, and I 
have always loved the stories behind the building of edifices — 
houses, skyscrapers, dams, stone walls. My father was a stone- 
mason, and he remembers all his walls — the one where he 
forgot an anchor stone and was called back, a year later, to pick 
up the washed out section of wall and rebuild it — the one where 
the customer was running out of money and insisted that my 
father complete the job by using oversize stone in the backcourses 
(my father still sees the bulges in the wall where those stones 
shifted and marred the lovely field-stone front of his wall). In 
each of those stories is a lesson about building stone walls, if 
one cares to listen closely and learn. Computer programs are 
edifices, too — edifices of the mind. This chapter describes the 
"who" and "how" of their construction — the builders and 
methods — and in these stories, there is much to learn, too. 

Each account illustrates an approach for the design and 
development of CAC software. In that sense, the accounts 
provide and illustrate development models, and while there is 
certainly overlap between and exceptions to those suggested 
models, my review of the literature, my discussions with CAC 
specialists, and the interviews that form the heart of this study 
show the accounts to be reasonably typical descriptions of the 
primary approaches to current CAC software development. From 
the analysis of the data, five areas of concern emerged for 
structuring and illuminating the narrative accounts. They are as 
follows, and in the accounts they share the titles listed below: 

1. Getting Started /Origins and Models: Identifies the roots of 
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the development effort, the inception of the program: seeing 
and reacting to other programs, attending a conference, 
wanting to program an exercise, responding to a research 
problem, or attempting to model certain writing behaviors. 
This discussion also attempts to identify models of the 
writing process or behavior, if any, on which the designer 
based her programming effort. 

2. Design and Development: Describes the people involved in 
the development effort, how they worked together, and 
the way the program was designed. For example, if the 
project was a group effort, was responsibility divided up, 
or was the collaboration less structured? Did the designer 
also write the program code? 

3. User Input and Program Revision: Examines the way user 
feedback is utilized during the development and revision 
stages of the development effort. This discussion also 
examines the way revision of the program takes place. 
Some of the issues covered include field testing, methods 
of evaluation, types of user feedback, and impediments to 
revision. 

4. Funding: Examines the funding for the development effort. 
This discussion includes such areas as the benefits of for- 
profit software marketing, the role of defense-related fund- 
ing, and the general lack of funding for some models of 
software development. 

5. Institutional Reward and Recognition: Examines the response 
of academic institutions to the design efforts of faculty, 
especially in terms of acknowledgment, release time, and 
the treatment of CAC software in tenure and promotion 
deliberations. 

Woven into this fabric are the idiosyncratic details of individual 
lives and the contexts that influenced the software. This chapter 
also provides insight into the people who are creating CAC 
programs. Each model description ends with a brief review of 
its most important characteristics. 

Taken as a group, the four principal models for software 
development in this study offer a rich diversity of approaches 



22 



Writing Teachers Writing Software 



and aims, a diversity not suggested by the scarcity of literature 
devoted to the subject of academic software development. In 
their general survey of institutional models for software devel- 
opment, Jack Chambers and Dorothy Ohl Lewis (1988) simply 
divide those development projects into sole designer and team 
design approaches (pp. 95-97). In fact, there is something like 
a continuum chat reflects finer and more important differences 
between development approaches than a simple delineation 
based on the number of participants involved. 

At one end of the continuum is what I term the Lone Developer 
Model. In this model, we find a writing teacher whose classroom 
experience suggests a need for a certain kind of program that 
does not seem available in the marketplace. With little access to 
funding, the teacher adopts a practical approach — she uses 
whatever equipment she has available to her and enlists the aid 
of any willing volunteer She most likely tries out the program 
on her own students and makes changes based on what she 
sees them doing with it. If the program gets complicated, perhaps 
she hires a programmer. In terms of technical sophistication, the 
program is modest. Yet, it fills a niche, finds its way into the 
classroom immediately, and becomes, hopefully, a useful tool 
for that part of the writing process which it addresses. That is 
;he best reward the designer is likely to receive, for these are 
the kinds of efforts that English departments prefer to lump in 
with general class preparation — with the nitty gritty of pedagogy. 
As such, little notice is likely to be taken of the program. 

At the other end of the continuum is the Research-Based Design 
Team, a group of CAC researchers and specialists from various 
fields (education, psychology, possibly computer science) who 
work on programs that advance research interests. They work 
from highly defined and empirically based models of the writing 
process, and their programs are structured around those models. 
These programs are likely to make use of very sophisticated and 
expensive technology, and they require a great deal of funding. 
Thus, government agencies, defense-related concerns, and cor- 
porate sponsors are often part of the funding picture for these 
projects. Perhaps for that reason, or because of the competition 
for limited funding, the individuals interviewed for this model 
were reluctant to discuss exactly who is funding their work or 
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the dollar amounts of their project budgets. It is clear, however, 
that those funding sources e:cert some influence on the devel- 
opment process and on the final program design. These are 
programs that may not make their way into most classrooms 
for many years, which is par for the course in this development 
model, given that the primary aim of the work is research 
oriented. It is their research focus that gives these projects their 
value within the institution. This work, as long as it results in 
publishable research, is viewed favorably in the reward structure 
of the university. In this model, CAC design weighs favorably 
in decisions about tenure and promotion. 

Along the continuum, closer to the lone programmer end, we 
find the Small Design Group Model In this model, one finds a 
small group of writing teachers, pooling their energies and 
talents, to produce software. Like the lone programmer, they 
are likely to base their program on their classroom experience 
and their observation of students; yet their program is likely to 
be more ambitious in its pedagogical goals and technical so- 
phistication than those in the lone programmer model. The 
developers usually pursue funding at the institutional level or 
through lower-level grant programs (say $10,000 versus the 
$450,000 figure that a researcher like John Smith uses as an 
example of a project budget; J.B. Smith, 1989, interview). Much 
of this funding will be used to hire programmers. The work of 
these designers is likely to receive little reward or recognition 
from their departments and institutions, even if the program 
enjoys praise from others in the field. 

Further along the continuum from the small design group is 
another group of academics, but in this scenario — the Entrepre- 
neurial Design Group Model — the designers form a private com- 
pany for the development and distribution of their software. 
These designers see themselves as CAC specialists, and as s.ich, 
they are likely to have more technical expertise than their peers 
in the previous two models. For example, they are likely to do 
their own programming and to see that task as more enjoyable 
and valuable than do nonprogrammer-designers. Their combi- 
nation of expertise, their power over their own work agenda, 
and the profits they derive from the sale of their software allow 
these designers more time for "playing' 7 with program design 
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and for revision of the program itself. Because their programming 
efforts exist outside the university, issues of departmental reward 
and recognition do not obtain. 

Related to the entrepreneurial model and included in that 
discussion as a sort of subset is the Professional Software Devel- 
opment Model In this model, software is developed for profit, 
but the designers are not academics. While they may have 
experience as teachers of writing, these designers are now full- 
time software developers and therefore must be more sensitive 
to the marketplace than the designers in the other models. That 
marketplace is likely to include the classroom as only part of a 
larger target group, usually the business sphere. Because they 
design for a business market that, in general, possesses more 
powerful hardware and larger pocketbooks than do writing 
programs, they can design more technically sophisticated and 
demanding programs than the developers who sell for the writing 
classroom. 

Each approach is illustrated and explored through the accounts 
and comments of designers like Mimi Schwartz, Nancy Kaplan, 
Taylor, and Smith. Their stories help define the approaches, yet 
this is not to say that the experience of any one designer 
encompasses the experience of. all other designers within the 
model. There is no logical reason, for example, why a designer 
in the lone programming model could not work with a more 
formal design protocol than Schwartz did. Yet, the accounts 
reveal a number of reasons why most designers in that model 
would not. In that sense, in the exploration of why the stones 
were placed in the way they were, if you will, the accounts are 
both illustrative and representative of each model. 

The development models address the first two of the five 
areas of inquiry outlined in chapter 1: the who and how of 
current program design. Through the stories of the designers, 
one learns how CAC software tools are built, as well as the 
fundamental relationship of that process to their final shape. 
Before exploring the future direction of CAC software devel- 
opment, we must take this first step and find out where we are 
today. 
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The Lone Developer Model 

This model for program development is closest to the one 
John Kemeny and the developers of BASIC imagined in 1958, a 
model in which classroom teachers would have the skills and 
resources to create their own computer programs. James Strick- 
land's 1981 program, FREE, is an example of such an effort in 
CAC programming. Strickland was inspired by the model of 
writing in Peter Elbow's Writing without Teachers (1973) and 
knew that no CAC program existed which reflected the pedagogy 
suggested in Elbow's book. Strickland wrote his freewriting 
program in BASIC on an Apple microcomputer with 48k memory. 

My research suggests that Strickland's example is now an 
exception in the field of CAC development, for two important 
reasons. One is the development of higher-level programming 
languages which more easily meet the complex programming 
demands of increasingly sophisticated CAC programs, but which 
are often beyond the ken of classroom writing teachers. These 
languages, such as Turbo Pascal, C, and a new generation of 
object-oriented program languages such as C++, often mean 
enlisting the aid of a hired programmer. BASIC has been rewritten 
in an attempt to meet more sophisticated needs, but none of 
the program developers I spoke with now uses BASIC. The 
second reason, as just suggested, is the increasing sophistication 
of CAC programs. When Strickland was asked for a copy of 
FREE, he hesitated and expressed embarrassment at what he 
called its ''primitiveness'' (Strickland, 1988, interview). He pointed 
out that "any word processing program can now do what I was 
trying to do with FREE." By way of contrast, a recently developed 
program like Dan Burns's Thoughtline requires substantial com- 
puter memory, processing speed, and hard drive space. Also, it 
was written in LISP, a programming language designed for 
artificial intelligence programs. Programs like Thoughtline require 
not only more technological knowledge on the part of the 
designer, but also a great deal more development time, as much 
as three to four years (Selfe, 1989a, interview), as well as 
technological lesources. As Selfe argues, "These are beyond the 
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reach of the everyday classroom teacher." Mimi Schwartz's 
experience in the development of Prewrite is perhaps a more 
accurate representation of the "lone" programming model as it 
exists today 

Mimi Schwartz is an associate professor and director of the 
writing program at Stockton State College in New Jersey Schwartz, 
possessing the energy of her native New York City engages in 
a wide range of professional activities. She teaches a variety of 
writing courses, has authored the texts Writing for Many Roles 
(1985) and Writers' Craft Teachers' Art (1991), a forthcoming 
memoir entitled Swimming above the Black Line, a guide to writing 
college entrance essays, and, at present, is completing a novel. 
She seems to possess a natural inquisitiveness. As a result, the 
impetus to create a software program was, for her, a mix of 
curiosity, challenge, and a nose for the market niche. She recalls: 

I guess the software program ... I just sort of had an idea. 
I've done a number of these kinds of things. I wrote a 
booklet, How to Write Your College Application Essay, that 
did very well I'm still getting good royalties from that. So 
I was thinking, the software thing intrigued me, so I decided 
to see what I could do with that. (M. Schwartz, 1989, 
interview) 

The inspiration for the actual program, according to Schwartz, 
came from seeing a presentation by Hugh Burns and from a 
desire to humanize the prewriting programs then available. She 
says: 

I [wanted] to write a program that was very uncomputerese. 
That was the challenge. I didn't like all the jargon that was 
built into some of the early prewrite programs. (M. Schwartz, 
ibid) 

Schwartz set out to design a prewriting program that would 
"get things out on the page, to look and see what's there that 
looks interesting." 

She claims that the program was not based on a formal model 
of the writing process; however, the structure of the program 
corresponds closely with her later description of how she believes 
writing takes place: 
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Writing is, well, the aim is to try to get a lot of stuff out, 
to see what's there that looks interesting, and build from 
that. The process of building is, well, you build and you 
expand out, and then you come back, and it's much more 
of a holistic process. (M. Schwartz, ibid) 

Interestingly, the structure of the program follows three cycles 
of expansion and compression which are similar to her descrip- 
tion of the writing process quoted in the passage above. Following 
is one such cycle from the program: 

One way to find a topic is by freewriting. Just type in the 
first five ideas that come to mind and don't think about 
whether they're good or not. Try it! Okay Are you interested 
in writing about any of these ideas? (A "Yes" answer 
produces "Which one?" A "No" answer sends you back to 
freewriting or allows you to exit the program.) 

Think about a working title for your piece (less than one 
line). 

When you've moved through this cycle from freewriting to title, 
you begin the next cycle with another expansive question — 

"Why did you choose to write about ? (Answer as fully 

as you can)" — and the cycle is repeated. Even though Schwartz 
asserts that the program was not based on a formal model, the 
"building out and coming back" she describes as taking place 
in the writing process are indeed reflected in the structure of 
Prewrite. It is interesting to note that Schwartz seemed at first 
unaware that the structure of her program should so closely 
parallel her own model of the writing process. She sees the 
program as a more unstructured and creative way to "get over 
the blank page," yet an analysis of the program reveals it to be 
highly structured, and her interview comments suggest that her 
sense of the writing process acted as at least a subconscious 
model in the design of the program. 

The complexity of the programming effort dictated that 
Schwartz, unlike Strickland before her, could not work alone. 
Indeed, my research turned up very few examples of teachers 
truly working alone in the development of a CAC program. 
While Schwartz is solely responsible for the design of the 
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program, she collaborated with a series of programmers to create 
its actual working substantiation. Working with her high-school- 
age son, Alan, who could program in BASIC, Schwartz developed 
a prototype of Prewrite that she used in the computer writing 
lab at Stockton State, receiving positive student response. Re- 
alizing that developing a final version of the program was 
beyond her son's abilities, she hired a programmer. Even though 
Prewrite is a relatively unsophisticated program in terms of ite 
structure — it is a straightforward prewriting heuristic that prompts 
for user response, but does nothing with those responses beyond 
printing them — the programmer whom Schwartz hired to rework 
the prototype version, written in BASIC, rewrote the program 
in a higher-level language. 

While Schwartz did not explain, in her interview, why the 
programmer used a higher-level language, there are a number 
of rationales for doing so. Such a rewrite may have offered the 
programmer more modularized code, making subsequent revi- 
sions easier. He may have n written the code to make it more 
economical in size, reducing i s memory requirements and mak- 
ing it attractive to more of the "low-end" users, those with less 
powerful machines. One of the positive results of rewriting 
Prewrite was that the program could then allow teacher-users 
to customize and monitor the program itself. 

The difference between Strickland's experience, doing his own 
programming, and Schwartz's, working with a programmer, 
might seem rather insignificant, but in fact, the collaboration of 
program designer and programmer is one that can directly affect 
the final design of the program and even compromise the 
designer's original aims. Schwartz recalls working with her 
programmer: 

I put an ad in the paper for a programmer. I was looking 
for someone who was not into computerese, so I hired 
someone who was a programmer, but had a Ph.D. in 
psychology. I figured he would be humanistic. Which was 
wrong. The battle was always that I kept on saying I wanted 
it [Prewrite] to be a program that people who knew nothing 
about computers could use. And programmers just don't 
think that way. His problem with me was that I had 
absolutely no idea how programming worked, so I had no 
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idea what things were easy for him to do and what things 
were hard. (M. Schwartz, ibid) 

For example, Schwartz remembers her negotiations with the 
programmer over the initial user sign-on. In keeping with her 
desire for a more humane voice in the program, she wanted the 
program to say, "Hi! What's your name?" The programmer 
needed to have the full name with a verification (i.e., "Your 
name is John Doe. Is that correct? [Y/N"]). His argument was 
that, without verification, the user might have a typo in her 
name and would be unable to recall her file in future work 
sessions. In addition, according to Schwartz, the programmer 
saw the language of the verification request as appropriate for 
the discourse of computers: "He couldn't see that this discourse 
wasn't appealing to people who didn't buy into it," she asserts. 
Schwartz's argument had to do with her theory of writing: 

In my writing process ... the thing that I realized is that 
all ny writing begins with a voice. So that if I can't get the 
voice right, I can't write it. So, that initial confrontations 
over the opening screens were very important to me, because 
I couldn't see the rest of it coming out. (M. Schwartz, ibid) 

The final result was a compromise in Prewrite's opening, with 
the humane voice Schwartz demanded, followed by a slightly 
more computerized voice asking for the verification the pro- 
grammer needed: 

Hi! What's your full name? 

Your name is Is this correct? (Y/N) 

The program then goes on to address the user by his or her first 
name. A sense of disjointedness seems to result from the 
informality of the enthusiastic "Hi!" followed by the formality 
of a request for a full name which is then repeated back to the 
user. The verification could have taken place during a later save 
function and not impinged upon the opening of the program. 
This is a case where the designer's aims were needlessly com- 
promised by a programmer's strict adherence to what he felt 
was good programming practice, putting his criteria for the 
program ahead of the designer's. 
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Recalling her work with a hired programmer during the 
development of Wordszoork (formerly Wordsworth II), Cynthia 
Selfe echoes Schwartz's experience. Like Schwartz, she had to 
negotiate with her programmer: 

I finally said, "Hey, look! You're making the technology 
constrain the writer. You have to settle for some of these 
things [design characteristics the programmer disagreed 
with]." It was a process of negotiation. So it was really 
frustrating when we were in it, but in retrospect, it was 
almost funny. I know that we learned things through the 
experience of coding. (Selfe, 1989a, interview) 

The gap between a designer's original vision of a program and 
its final shape may be unnecessarily widened when the designer 
lacks programming experience. As Helen Schwartz, creator of 
the award-winning CAC program SEEN, says of her experience 
with a hired programmer, "I was not in a position to evaluate 
his work. For example, choosing what language to program in. 
I had no way of knowing if that decision was correct or not" 
(H. Schwartz, 1992, interview). This situation leaves a great deal 
of power in the hands of the non-content expert collaborator 
Selfe agrees, and she suggests that designers should know at 
least some programming, even if they are not going to write 
their own code. Having had some PASCAL, she recalls, "I was 
at least able, when the programmer had a failing of imagination, 
to say, 'Yes, you can do it! 7 But I was not able to direct or 
guide" (Selfe, 1989a, interview). Her sentiments were echoed 
by many of the program developers I interviewed; but even 
Helen Schwartz, who had a good working knowledge of BASIC, 
finally concluded about working with hired programmers: "I 
never want to do it again." 

Fred Kemp argues for a return to program designers who also 
write their own code. He believes that the act of actually writing 
the code for a program generates new ideas for the design of 
that program and allows for quick and easy revisions: 

There is something in the actual process of writing the 
program that acts as an invention heuristic itself. It generates 
ideas, it generates paths for you to take, which when filtered 
through your professional training in composition and rhet- 
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oric, can generate new ways of handling a program that a 
nonprogrammer just wouldn't discover. (Kemp, 1989, in- 
terview) 

The combination of programming expertise and the classroom 
teacher's immediate access to classroom use and observation 
quickens the design-revision cycle. As Kemp notes: 

The second thing is that the teacher-programmer can observe 
the programs in action, and when something happens in 
the program, whether it's an interface screen situation or 
some part of the central mechanism of the program, the 
teacher is sitting there evaluating it in terms of pedagogy 
and instructional approach . . . When I see things happen 
on the screen, in my mind I'm thinking "program lines," 
and this, I think, is important. (Kemp, ibid) 

Without having to negotiate program revisions or having to 
follow more structured design protocols, the teacher-programmer 
can substantially reduce the time lag between user input and 
revision: "The next class comes in and you've already dumped 
the program — the revision — in" (Kemp, ibid). 

Unfortunately, the faculty member who decides to design and 
develop a CAC program will most likely work with a program- 
mer-collaborator, despite the limitations of such an approach. 
The complexity of higher-level programming languages and the 
time it takes to become expert in their use make the training 
time prohibitive for practicing classroom teachers or imposing 
to newcomers. The demands of writing, compiling, and debug- 
ging thousands of lines of complicated program code are likely 
to keep the number of practitioner-programmers small. 

On the other hand, new hypertext and hypermedia authoring 
systems like HyperCard and ToolBook, which are based on object- 
oriented programming languages, allow even nonprogrammers 
to create highly sophisticated software programs. These programs 
have the potential to revive the lone faculty-developed software 
program, at least from a technical perspective (see chapter 4). 

Schwartz completed a "rough" version of Prewrite and made 
changes in the program on the basis of user response, specifically 
the input of high school teachers who were using the program 
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in their writing courses. That input, combined with the informal 
observation of her own students in the Stockton State computer 
writing lab, led to the removal of a number of the program's 
audience-based questions. Schwartz did no formal testing of the 
program. This use of user input and informal observation for 
program revisions was the common method of testing programs 
in three of the four design models suggested by my research. 
Only the large design teams, following highly structured devel- 
opment protocols, did formal testing of programs during the 
development process; the other subjects cited a lack of necessary 
staff and funding. 

Soon after completing Prewrite, Schwartz entered into dis- 
cussions with CONDUIT, the software marketing consortium. 
They requested a number of revisions in the program that 
included new functions and would require substantial amounts 
of programming. Schwartz broke off those discussions, refusing 
to conduct such a complete reworking of the program. She 
comments, "It's not like someone asking you to rewrite a piece 
of writing. For that, you can sit down and do it. With software, 
you need to find a programmer and begin the process again. 
It's a much bigger . . . it's a different psychological thing" (H. 
Schwartz, 1992, interview). Later, when her eventual software 
publisher, MindScape, saw a potential elementary school market 
for Prewrite, Schwartz did revise the program. In this case, 
revising the software meant merely changing and decreasing 
the number of prompts. The former activity was built into the 
original program and required no real reprogramming. 

Schwartz received no outside funding for the development 
of Prewrite. She paid her son two hundred dollars for his 
programming work in the development of the prototype; the 
informal sales of the prototype paid for the programmer she 
eventually hired to write the final version of the program. Since 
the program was written on an Apple and was designed for the 
Apple microcomputers in her computer lab, the hardware re- 
sources Schwartz needed were readily available. In terms of 
funding and resources, this model for program development 
falls at the least expensive end of the design and development 
continuum, the sphere characterized by the least amount of 
institutional support and recognition for such efforts. Aside from 
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watching her students use the program in the lab, all the 
development was done off campus, without the aid of college 
computing resources. While she enjoyed recognition for her 
instrumental role in acquiring the first computer writing lab in 
New Jersey, she received no formal recognition for her software 
work from either her department or her college. 

However, Schwartz would not overemphasize the value of the 
program or even of computers in general. Of all those interviewed, 
she was the least enthusiastic about technology and the least 
willing to acknowledge its deeper noetic implications: 

It's a useful tool . . . There are certain people that definitely, 
you know, people who have spelling, handwriting problems, 
writer's block — I will push them more toward the computer. 
It's like a good typewriter; it's a good tool. I'm not hooked 
on it as anything more than a convenient technology. (H. 
Schwartz, 1992, interview) 

Indeed, Schwartz would have done no more work in software 
development regardless of institutional reward: "I think it can 
help people, and there are certain people it can help a lot, but 
I don't think it's worth the extra pedagogy to do this." In this 
sense only, Schwartz's experience is not typical of other single- 
person program designers. While most others using this approach 
attempted no more in the way of new program design, they all 
remained committed to using technology and convinced of its 
significant impact on composition theory and pedagogy. 

What can be termed the defining characteristics of the lone 
program developer model? First, the effort is seldom, if rarely, 
the work of a single practitioner/programmer. It is more likely 
to be a partnership between an expert, usually the writing 
teacher who is also a computer enthusiast, and a programmer. 
This collaboration seems to require lengthy negotiation and may 
ultimately constrain some of the creativity in design concepts. 
Program development in this model is informal. The idea for 
the program is likely to come out of classroom practices and 
needs, perhaps the desire to computerize a favorite pedagogy, 
as in the case of Strickland's FREE and Schwartz's Prewrite. 
Revisions of the program are more likely to be based on user 
feedback and informal observation of its use than formal site 



34 



Writing Teachers Writing Software 



testing. In part, this may be a result of the inadequate funding 
these efforts are likely to receive, as well as the general informality 
of the development model. Because these programs are designed 
for existing classroom technology (for example, microcomputers 
like the Apple He, instead of expensive Sun terminals common 
to engineering departments) technological resources tend to be 
readily available. The expense of a programmer, a relatively 
modest oiv: ;J iven the type of programs developed in this model, 
is the greatest cost in the development effort. Mv research 
suggests that there is little institutional support for these kinds 
of programming efforts. 

The Small Design Group Model 

Moving up the continuum, the next model suggested by my 
research is what might be termed the small design group. The 
small design group is usually a collaboration between two or 
three practitioners and often a hired programmer, though one 
of the designers may also know some programming. There are 
numerous examples of such small design group programs: Valerie 
Arms and Jim Gibson's Create /Recreate, Ray and Dawn Rod- 
rigues's Creative Problem-Solving, Donald Ross and Robert Rasche's 
Eyeball, Helen Schwartz and Louis Nachman's Organize, and 
Cynthia Self e and Billie Wahlstrom's Vfordswork. Of the programs 
included in this study, the development of Prose is a good 
example of this design model. It was the creation of Nancy 
Kaplan, Stuart Davis, and Joseph Martin, all lecturers in the 
writing program at Cornell University at the time of the program's 
creation. 

The design and development of Prose, a program designed to 
facilitate instructor feedback on student texts, followed a much 
more formal track than did Preivrite. The original idea developed 
out of classroom practice, specifically the observation of instructor 
feedback on student texts and a desire to improve the quality 
of that feedback. Kaplan recalls: 

Part of my interest in the project to begin with, was not 
so much how it *.vas going to have an immediate impact 
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on students' writing behavior or their sense of their own 
autonomy and authority over their texts, because I've always 
known that instructors are far too intrusive in their students' 
work and that students are far too docile in that pro- 
cess ... In my particular position, you see all kind ; of horrors 
wher you mark student papers; and it [the program] seems 
like a way — a fairly nonthreatening way — of handing in- 
structors a new mechanism for doing their work that will 
encourage them to think about that work in new and 
different ways. (N. Kaplan, 1989, interview) 

To effect such an impact on instructors, the design team envi- 
sioned a hypertextual program that would allow nonsequential 
creation of instructor comments through flagging and window- 
ing, as well as layered handbook and workbook screens for 
mechanical errors. 

The program has a twofold goal. It offers instructors mech- 
anisms for giving useful feedback on student papers — modeling, 
in effect, the designers' sense of what feedback should look like. 
The way that feedback is presented to students offers them an 
alternative model of revision from the one the designers believed 
they saw in the classroom. Kaplan describes students' poor 
revision behavior: 

What I used to see, or thought I used to see, was a student 
who looked at the piece of paper on which his text and my 
responses were written, and who then went to whatever 
was closest to the top and made a change, and then moved 
on and worked from the top down, word by word. You 
saw a lot of tinkering at the word and phrase levels, and 
almost no conception of revision in any domain other than 
the word or phrase. (N. Kaplan, ibid) 

The model that underlies Prose provides a global view of the 
text, first, and a prescribed order of revisions that may only 
address wordr and phrase-level changes, last. Kaplan describes 
this model in terms of the program: 

To us it seems really important that the summary comment 
[the overall commentary that instructors typically append 
to the end of a student essay] actually sort of lay out the 
whole project [the revision of the student paper] as we 
envision it. But I also use the work-order feature to help 
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students get a sense of the priorities, partly by making a 
very dear distinction for my students between comments 
and "please revise" remarks, and occasionally by setting a 
work order to first take a student some place other than 
the head of the document. (N. Kaplan, ibid) 

The design of Prose is built on this model, which the designers 
hoped students would adopt as a more effective approach to 
revision. 

A program of this sophistication requires a great deal of 
programming and revision, which requires funding. Therefore, 
before the development of the program could proceed very far, 
the group was faced with writing a funding proposal. A funding 
proposal requires, early on, a clear articulation of design goals. 
If the design of a program can be likened to the creation of 
written text, then these "writers" had to consider audience 
(members of the grant committee) needs early in the design 
process; they could not proceed very far into the development 
of the program by just "playing" with the design, at least in its 
broad parameters and stated goals. 

Once the proposal for Prose was accepted, the development 
process started in earnest. The collaboration of Kaplan, Martin, 
and Davis was unstructured; that is, each member had input 
into all the important design decisions, and the group worked 
toward some form of consensus. Kaplan says: 

We worked pretty well together. Yes, I would have to say 
that, overall, it was smooth, and we did a lot of talking 
through of the design issues. I mean, we always talked 
about this stuff anyway, so in a sense, the collaboration 
wasn't new. But there were some difficult moments — ac- 
tually, some really bad moments. But those usually occurred 
when we were feeling some deadline pressure, some pres- 
sure to produce. Then things got pretty heated; for example, 
when we were trying to finish up the documentation before 
sending the program off to Kinko's. (N. Kaplan, ibid) 

While Kaplan characterizes the collaboration as ''smooth/' her 
interview response suggests the difficulties that can come with 
collaboration among equals. Helen Schwartz speaks to this issue 
in recalling her collaboration with Jack Nachman, Organize: "It's 
a problem. We were two colleagues working together, so I 
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couldn't prod him, and he couldn't prod me. If you have unequal 
passion for a project, it's a problem" (H. Schwartz, 1992, 
interview). Kaplan said about the Prose project, "We don't talk 
about it anymore. We're still friends and we want to keep it 
that way!" (N. Kaplan, ibid) 

For most writing teachers who want to create software, the 
development effort takes place outside of their salaried institu- 
tional work. The long hours and necessary meetings must then 
impinge upon their personal lives, and that can create stress 
both within the group and within their individual spheres: 

I'm a single parent, but neither of my two collaborators 
have any children. So, there were times when we were 
working on something, and I just had to up and leave 
because I had to pick up kids from daycare, or just go home 
and cook a meal, or whatever it might have been. (N. 
Kaplan, 1.991b, interview) 

While much collaboration within the group took place around 
the coffeepot in the writing workshop conference room, or in 
the suite of offices the three colleagues shared, there were also 
many 10 p.m. meetings after Kaplan's four- and seven-year-old 
daughters, Erica and Eva, were tucked into bed. She remembers, 
"Oh, 10 p.m. to 2 a.m. were prime-time Prose work hours." The 
two children, who once earned a dollar an hour to repeat the 
same combination of keystrokes on the computer until a hard- 
to-track-down bug occurred, expressed considerable resentment 
at the time Kaplan had to spend working on Prose. Kaplan now 
suggests that software development, when it takes place outside 
of professional duties, is almost impossible for anyone acting as 
a primary parent. 

While the development effort was informal, by the later stages 
of the project, the individual strengths of the group members 
emerged. Each of the designers started taking responsibility for 
specific areas of the work: 

I did most of the program debugging, mostly because I had 
more patience, and I turned out to be better at it. So I did 
most of the negotiating with the programmers. Meanwhile, 
someone else would take over writing the documentation. 
(N. Kaplan, 1989, interview) 
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Because none of the three designers was an expert programmer, 
the group hired five student programmers during the course of 
the program's development and wrote none of the actual code 
themselves. But because the designers had some programming 
experience, when they had to negotiate design decisions with 
their programmers, they could do so with a sense of what was 
possible and reasonable, similar to the experience Selfe described 
earlier. Kaplan argues that hiring a programmer may mean losing 
the heuristic value of writing code, but this gives the designers 
substantially more time to work on other project concerns, such 
as writing documentation, negotiating with distributors, revising 
the program, and so forth (N. Kaplan, ibid). 

As in the case of Prewrite, the primary mechanism for eval- 
uating the program's design was informal observation of students 
who were using the program. For example, Kaplan observed 
many students who used Prose to read their instructor's revision 
comments, but who then moved to another word processor to 
actually rewrite the document. Moving out of the program often 
meant circumventing the guided revision effected by the instruc- 
tor through the program's "work order" function. (This function 
forces students to make textual changes in a prescribed order.) 
Kaplan blames this phenomenon — of students leaving the pro- 
gram to make their actual revisions — on a technical constraint 
which the developers had to ccept: 

Well, part of the reason for that is one of the disabilities of 
Prose — and it's something we are absolutely, at least for 
now, stuck with — namely, that you can't do face and font 
changes, that you lose a lot of formatting. In a well-designed 
computer environment, that wouldn't be . . . Now when we 
started this project, Apple kept promising a different core 
editor. The editor we're using comes supplied with the 
machine, so to speak. And it's pretty good— by IBM stan- 
dards it's a "wowser" — but it's not good enough, because 
we're spoiled by face and font changes, and ruler changes, 
and other things. And they kept promising us that they 
were going to replace the thing at the heart of it, which is 
called "text edit," with something else called "core edit," 
which would allow us what is called a "rich-text format" 
But it never happened, and they abandoned it. So we were 
pretty well stuck with what we had. (N. Kaplan, ibid) 
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This is a good example of the way a technological limitation 
can impair program design and encourage some users to ignore 
one of a program's central functions. Kaplan believes the work- 
order function effectively forces the student to follow and thus 
learn effective revision strategies. Kaplan's conclusion— that the 
program's poor editor is driving the switch from Prose to another 
word processor during the actual revisions — reveals the way a 
technological factor can have a very real impact on program 
design and effectiveness. 

While there was little the designers could do to rectify the 
problem, other problems they observed were addressied during 
program revisions. Throughout the program's three versions, 
revisions in design were often substantial, with a major overhaul 
of the file structure occurring between the second and third 
versions. The goal of these revisions was to give instructors and 
students more flexibility in the program, allowing students, for 
example, a "skip" function that allows them to skip over an 
instructor's "Please Revise" and "Comments" messages. As in 
the case of Prewrite, the revisions were largely based on user 
feedback and the informal observation of student users in the 
university writing program. As far as evaluating the program's 
success in meeting its main design goals, no formal testing was 
performed: 

Nobody's had the time to actually look at how instructors 
use it and whether their practice— using this kind of tool 
to respond to student grading — differs from their practice 
when they're using other tools, other ways of representing 
their work. (N. Kaplan, ibid) 

In fact, not only has testing not occurred, but there are no 
current plans for future revisions to the program. Pre e is now 
in the hands of McGraw-Hill, who is marketing it, but who has 
not implemented any program revisions. 

A lack of formal funding is the primary reason for the lack 
of formal field testing and revision that the program now needs. 
The proposal for Prose was one of three computer project 
proposals the group submitted to Cornell University's College 
of Arts and Sciences and the one which was selected for funding. 
Additional funding came from an anonymous donor, from the 
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Cornell writing program, and from Apple Computer, Inc. While 
the program was funded, it was, for a program of this complexity, 
only adequately so. Kaplan points out: "We [received] from the 
institution a total of about $10,000 over three years, 
which . . . hardly [constitutes] massive support for a project of 
this sort" (N. Kaplan, ibid). 

While the funding saw the designers through the three-year 
development period and its three successive versions of the 
program, the designers had to compromise the design of the 
program, due largely to a lack of additional funding. To illustrate, 
Kaplan explains that in the original design, the preprogrammed 
examples could be changed by any given instructor: 

That was something which we had designed to be flexible 
when we first wrote the design script for it. We weren't 
sophisticated enough at that stage to know that you were 
supposed to write out specifications for [quadrules] and 
things. So we actually wrote it out, but with the time and 
money available, it just didn't happen. (N. Kaplan, ibid) 

The implication of that limitation for the program, according to 
Kaplan, is that the examples become stale for the student users 
and might not translate well into other learning environments 
at Cornell (N. Kaplan, ibid). However, the project budget simply 
did not allow for changes to the program's examples. 

Kaplan explains that the group's reluctance to do any further 
work with Prase stems not only from the rigors of the task ("It's 
really the hardest work I've ever done"), but largely from the 
lack of institutional support from Cornell. She points to the 
meager funding for the project, and to the university's lack of 
interest in the group's work. In terms of the encouragement the 
group did receive, the following excerpt is illuminating: 

Kaplan: Occasionally, someone said a nice word or two. 

LeBlanc: How about in terms of recognition since then? 

Kaplan: None. No release time. The three of us did this in 
addition to our full-time jobs [as lecturers in the writing 
program]. The only thing we got formally from the 
university was acknowledgment that the thing itself 
[Prose] belonged to us, so that if we could market it, we'd 
get the money. There's been an award [1987 NCR1PTAL/ 
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EDUCOM Distinguished Software Award]. That wasn't 
even announced . . . frankly, the writing program has 
invested very little in computer-aided instruction. It has 
no demonstrable interest. (N. Kaplan, ibid) 

It is interesting to note that even the Writing Project, which 
operates separately from Cornell's English department, failed to 
appreciate the importance of the group's work. That recognition 
has come from elsewhere, most notably in the NCRIPTAL/ 
EDUCOM award the program earned in 1987. 

To review, the small group model of CAC program develop- 
ment is a common one, accounting for 35 percent of the programs 
listed in Ellen McDaniers 1987 bibliography of CAC software. 
The groups normally include two to four designers, usually 
working with one or more programmers. The cost of program- 
ming normally demands the pursuit of outside funding, often 
through the home institution, as in the case of Prose. While 
inspiration for such programs might come from the classroom- 
based experience of the practitioner-designers, the requisites of 
proposal writing and group collaboration demand a highly 
articulated set of goals early in the development process, allowing 
for less of the "play" described by program developers in two 
of the four models under study. 

Because the program designers are writing teachers, first, and 
program designers, second, the development of a program, 
despite its rigors, must take place after the demands of a full 
teaching schedule. Indeed, 60 percent of the faculty program 
developers responding to EDUCOM's Academic Software De- 
velopment Survey cite the lack of release time as the greatest 
barrier to program development (Keane & Gaither, 1988, p. 56). 
Mirroring Kaplan's experience, Keane and Gaither report that 
"faculty members expending considerable effort were not sure 
that administrators appreciated the importance of their work in 
software development" (p. 56). 

This lack of support, both in terms of time and money, has 
design implications for this development model. It might mean 
not being able to make improvements in program design, or it 
might mean a lack of formal testing. In the case of Prose, it 
certainly means that desired improvements will not be made 
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and that the pedagogical effectiveness of the program may be 
impaired. 

The Entrepreneurial Design Group 

"Entrepreneurial design," a term used by Chambers and Lewis 
to describe the efforts of the single faculty programmer, is an 
increasingly rare approach to software design. It is used here, 
more aptly, to describe program design teams that operate as 
private, profit-making companies. The Daedalus Group, producer 
of both Mindwriter and Interchange, is one such company, highly 
respected by those in the CAC field, and useful for illustrating 
this approach to software development. Paul Taylor, Locke Carter, 
Wayne Butler, and Fred Kemp are members of this group. Hugh 
Burns and Jim Parlett both act in an advisory capacity to the 
group, with the former holding the title of chairman of the 
board. 

Interchange is a real-time conversation program designed for 
use on a standard file-transfer microcomputer network to create 
on-line classroom discussion. Unlike asynchronous systems such 
as bulletin boards or electronic mail, Interchange allows a group 
of users to be on-line at the same time and to converse on 
screen while displaying everyone's contributions. The program 
has five main components: 

1. The individual student writes on a "scratch pad," and when 
ready, can send the comment into the main display window 
on the screen of every participant signed-on to the con- 
ference. 

2. Comments appear on the main window as they arrive in 
chronological order, and the screen scrolls to make room 
for new incoming comments. Students can move through 
the text to reread what has been sent. In the latest version 
of the program, a hypertext component has been added 
which allows students the option of placing their new 
comments anywhere in the ongoing discussion, allowing 
for the elaboration of dialogues within the framework of 
the overall conversation. 
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3. Users can break off from the main conference and create 
subconferences to pursue new topics or lines of conver- 
sation. 

4. The program has a split-screen capability that allows a 
conversation to take place in one window while the text 
under discussion appears on another. 

5. The program can provide a hard-copy transcript of the 
conversation at the close of the session. 

The hypertextual component of the software allows strings of 
responses to be reconstructed from the overall conversation. 
Participants might, for example, ask for all the responses that 
included a given word or phrase. 

The program was developed in the windowless basement 
offices of the English department's Computer Research Lab at 
the University of Texas at Austin. On one side of the hall leading 
to the lab was a networked classroom of IBM PCs, and on the 
other side was the lab office, a messy and disorganized place 
full of computers in various states of repair, piles of programming 
manuals, errant floppy disks, and the constant flicker of computer 
screens — in short, a computer hacker's playground. Yet the 
hackers in this case were not computer scientists or engineering 
students. They were a group of English graduate students who, 
in 1984, took over the then new facility because no regular 
English faculty member knew what to do with it. In little time, 
this group of graduate students and self-taught programmers 
began to produce high-quality software that would eventually 
be integrated into something called the Daedalus Instructional 
System, which would win a 1990 NCRIPTAL /EDUCOM Award 
for Outstanding Software. 

The leader of that group was Fred Kemp, now an assistant 
professor of English at Texas Tech University. In 1984, after 
years of teaching in the secondary schools, he went to the 
University of Texas to complete a doctorate in literary studies. 
In the summer of 1983, Kemp and his wife had sold their house, 
preparing to move to Austin and begin his studies. With part 
of the proceeds from the sale of their home, he purchased a 
TRS Model 4. With little to do that summer, Kemp taught himself 
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how to program in BASIC. During his second semester in the 
program, Kemp heard that two faculty members had received 
a grant for new IBM computers but had then accepted teaching 
positions elsewhere. With no one capable of assembling the 
soon-to-arrive computers, Kemp volunteered, and Jerome Bump, 
then head of the English department and responsible adminis- 
tratively for the facility, promptly named Kemp — who had never 
used an IBM — assistant director of the lab. 

Kemp readily admits that his initial interest had more to do 
with idle curiosity than vision: 

Jerry didn't know anything about computers, and he kind 
of wanted to play with them. That was my motivation — to 
play. None of us really expected much to come out of this; 
we were just trying to see what we could come up with. 
Jerry, because he was interested in the computers, encour- 
aged that exploration. (Kemp, 1991, interview) 

Kemp soon saw the pedagogical potential of the computers, and 
though he received little initial support for his ideas ("Even Jerry 
said I was a little crazy at first;' he notes), Kemp had one very 
important predecessor at the university, someone whose work 
would prove influential and supportive. Hugh Burns, an Air 
Force officer who completed a doctorate in education at the 
university some five years before, had used as a germinal part 
of his dissertation research a computer-based invention program 
based on Aristotle's topoi, Burke's pentad, and the tagmemics 
of Young, Becker, and Pike. James Kinneavy, one of Kemp's 
professors and a member of Burns's original dissertation com- 
mittee, alerted Kemp to Burns's work. Kemp remembers: 

I got that dissertation and started looking at it, and it was 
the first time I realized that anything that small had ever 
been done about computers. That was in the summer of 
1984, and I decided then that we could take Hugh's pro- 
grams— TOPOI and TAGl — off the mainframe and put them 
onto a PC and run a study on them. (Kemp, ibid) 

Bump gave the project validity by dubbing it "Project Invention 
Heuristics" and left Kemp to program all day. Kemp was unhappy 
with the work of the computer science students who were hired 
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to assist him, so he spent hours by himself, working with his 
self-taught skills in BASIC, to make the original memory-inten- 
sive program operate on a simple PC, 

His efforts culminated in the event that moved him away for 
good from literary studies and into computer-based rhetoric: his 
delivery of a paper at the 1986 Conference on College Com- 
position and Communication, Actually, Bump had written a 
paper on his and Kemp's initial studies with the program they 
had entitled Idealog (later to become Mindwriter), but he was 
unable to attend the conference and asked Kemp to deliver the 
paper instead. Kemp is a big man physically. He is known to 
speak up and at length on the subject of computers and writing; 
yet, this was his first paper and he was, in his own words, 
"terrified" Adding to his state of anxiety was the fear that Burns 
might be in the audience and might object to some of the 
criticisms Kemp had of Burns's original program. He recalls that 
presentation: 

This was the first session at the 4Cs, and everybody kept 
telling me, "You'll be lucky to get five people." We had 
about 120 in there. People were standing along the back 
wall and outside into the hall, and I was scared to death. 
You couldn't miss this tall guy in the back of the room in 
a blue Air Force uniform. My wife Jan, the night before, 
found the 4Cs' letter and the part where they said they 
don't like papers read. So I had stayed up all night mem- 
orizing the thing .... When I delivered the paper, it ap- 
peared that all these beautiful sentences were coming off 
the top of my head without my ever looking at the pages. 
It went very well, and afterwards Hugh came up and really 
congratulated me. We talked for about thirty minutes, and 
he offered to be on my committee, and at that point — if 
we are going to talk about an epiphany — I realized this was 
important stuff, and I could participate as a colleague in 
this venture, (Kemp, 1989, interview) 

Kemp was the right person to undergo this conversion, for his 
personality and expertise helped draw other talented graduate 
students to the lab; not long after his CCCC paper, Paul Taylor, 
Wayne Butler, and Locke Carter joined the staff. 

The formation of that original group was more propinquity 
than process. At a regional conference in Corpus Christi, Kemp 
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and Taylor ran into other University of Texas graduate students, 
including Butler and Valerie Balister. The latter pair had been 
doing research and presenting papers on social constructivist 
theory, and at dinner, as Butler puts it, "theory met computers" 
(Butler, 1991, interview). Butler recalls: 

It was kind of funny. The Computer Research Lab at that 
time had Fred and Paul and thirty or forty computers — and 
no students. It was at that dinner that we said, "Well, let's 
see if we can turn it [the Computer Research Lab] into a 
classroom!" The next summer we started bringing students 
over. It wasn't an official thing — students didn't know the 
course was computer assisted when they signed up for it. 
We just sort of embarked on our own initiatives to do this 
team-teaching, collaborative learning 'n the network's class- 
room environment. (Butler, ibid) 

The strong connection between theory and software design, 
begun at a happenstance dinner, continues to characterize the 
development efforts of the group. In the case of Interchange, 
Butler's work in social constructivist theory would play a key 
role in the development of the program, 

Paul Taylor is actually the principal developer of Interchange, 
though as typical of development in the Daedalus Group, many 
of its members would influence the final shape of the program, 
Taylor, recently hired as an assistant professor of English at 
Tex^s A&M University, is in many ways Kemp's opposite. Where 
Kemp is large and friendly, Taylor is almost ascetic in appearance; 
where Kemp is familiar and outgoing, Taylor is rather shy and 
softspoken; and where Kemp enjoys all levels of the Daedalus 
Group's work, the design, the marketing, the research and 
conference papers, Taylor's first love is the solitude and exactitude 
of writing program code. Indeed, in the last pursuit he is probably 
the best programmer of the group. For example, the inspiration 
for Interchange came from an academic conference, the 1987 
Conference on College Composition and Communication, where 
Fred Kemp saw a demonstration of a rudimentary real-time 
conversation program designed by Trent Batson at Gallaudet 
University Kemp returned to Austin and described what he saw; 
Taylor made it happen. 

At the time, the Daedalus Group had not formally come into 
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being, though all its future members were working together in 
the research lab. Taylor recalls: 

Fred came back [from the conference] and started talking 
to the staff members in the lab, primarily Locke Carter and 
myself, about the possibility of our writing such a pro- 
gram ... We tossed the idea around for a month or two, 
and together we actually worked out some of the technical 
problems, as well as some of the enhancements that we 
felt were important for the program to actually be useful. 
And then, after we had kicked that around for a month or 
two, I actually sat down and wrote the program. (Taylor, 
1989a, interview) 

Like Kemp, Taylor was a self-taught programmer, learning BASIC 
on a Texas Instruments PC he had bought in 1984. He and 
Locke Carter spent the better part of a day talking through some 
of the large technical obstacles in writing the program. Indeed, 
they talked so long that Taylor became hoarse and had to take 
the next two days off, too sick to teach or to attend class. It was 
a fortuitous illness. When he returned to the lab two days later, 
he came carrying the largely completed program code for Inter- 
change (the program was then known as Forum but would be 
renamed later). 

Unlike the programs from Kaplan's group, Daedalus Group 
programs are developed first by a principal designer, who then 
calls upon other group members for input, which he can draw 
upon as the need arises. For example, Taylor gives Kemp credit 
for introducing the idea and elaborating on Batson's design, and 
he cites Carter's technical expertise and working through of 
major design questions. He admits that he wrote the program 
without any formal knowledge of social-epistemic theory: 

That [social-epistemic theory] was all new to me 
then . . . That's why it's so important to emphasize that this 
has been a collaborative effort, because others in the lab 
who were talking about this were familiar with the social 
epistemic. Fred certainly was, and another one was Wayne 
Butler, who was around the lab at this time. (Taylor, ibid) 

Instead, Taylor, who others in the group describe as a program- 
mer-perfectionist, admits he wrote the program for the "fun" 
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of overcoming the technical challenges: "I enjoy programming, 
and I enjoy problem solving." He admits that he did not see 
much use for the program and credits Kemp with the vision of 
its classroom value. Kemp, on the other hand, gives Taylor credit 
for being able to handle the tough programming problems posed 
by Interchange's design: "He's a much more meticulous pro- 
grammer and much more thoughtful — I'm a very slapdash, 
hacker-type programmer" (Kemp, 1989, interview). 

All of those involved in the Daedalus Group stress the 
importance of programming knowledge and collaboration. Be- 
cause each person involved in the development of the Daedalus 
Instructional System could program in PASCAL, with its easily 
transportable blocks of code, each could contribute to parts of 
an individual program. Kemp explains: 

PASCAL allows you to take twenty-five or thirty lines of 
code and dump them right into a program in a way that 
you can't in BASIC. So, we can use the same editor with 
Mindwriter, Interchange, and Descant, and in every other 
aspect of the larger system. Being able to work together in 
PASCAL encouraged a whole group of things that we were 
able to do, which I wasn't able to do working for a whole 
year and half by myself. When those guys came on board 
and we started using PASCAL, the production in that lab 
increased twenty fold. (Kemp, 1991, interview) 

Part of that productivity came from a hacker-like sense of play 
that characterized the group. Taylor says, "We just jumped in 
and tried things out. By programming, we could see possibilities. 
We'd write the program, put it in the classroom to try it out, 
and go from there" (Taylor, 1989b, interview). 

The informal collaboration of the Daedalus developers is 
similar to that in the small-group design work of Kaplan and 
her colleagues; yet the lack of outside deadlines, the fact that 
overall design goals do not have to be so clearly articulated at 
any early stage (as they must be in grant-funded programs such 
as Prose), and the programming expertise of all group members 
give this development model an air of high creativity It seems 
that ideas can "cook" longer in this model, and the program's 
shape can evolve more gradually. In the case of Interchange, an 
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idea comes from an academic conference and is discussed over 
time by a gro^ip of people who are trained both in composition 
and programming. Each member of the group contributes in 
different ways: Kemp with the inspiration for the idea and his 
pushing for its completion, Butler with his theoretical back- 
ground, Carter with his technical expertise, and Taylor as the 
principal writer of the actual program. Because the Computer 
Research Lab included a microcomputer network, the developers 
could test the program and subsequent changes through actual 
classroom use. Butler recalls, "We'd come back from class and 
say, 'We need a larger window here' or 'It needs to be quicker 
this way,' and then we'd make the changes and try it out again 
the next day" (Butler, 1991, interview). 

The prototype of Interchange was completed in 1987, usin^ 
Computer Research Lab hardware and Taylor's programming 
expertise. At about the same time, the group, led by Kemp, 
entered into negotiations with the university over rights of 
ownership for the software which the group was designing on 
their own time but on university property. The university claimed 
exclusive ownership of the software developed by Kemp, Taylor, 
and the others, and offered no portion of potential sales to the 
graduate students. Butler says, "I can't remember the details, 
but it was quite intimidating, and we realized, at that point, that 
anything we did on university property belonged to them" 
(Butler, ibid). The disagreement over ownership led to the actual 
formation of the Daedalus Group and the relocation off campus 
of all development efforts. The question of software copyright 
and distribution of royalties is an ongoing one for faculty software 
developers. Very few institutions have a set policy regarding 
software ownership, and there are no universal standards among 
the few that do (Keane & Gaither, 1988, pp. 56-57). In this 
case, the university argued that it had principal ownership of 
the software developed in the Computer Research Lab. As a 
result, the members of the Daedalus Group, which was formed 
in 1988, renamed all the software they had developed while 
working in the Computer Research Lab (this is when Forum 
became Interchange), rewrote all the program code, and cea^-d 
their software work at the Computer Research Lab. Development 
efforts moved to a room in Paul Taylor's modest suburban home, 
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as did all the operations of the newfound company, though they 
still used their software in the classes they taught at the university. 

Their observations of student users led to further revisions of 
Interchaiige, with a complete overhaul of the code in 1988, Based 
on their observations, Taylor and the others simplified the 
interface and made the message editor a full editor. The latter 
change was an attempt to make a stronger link between the on- 
line conversation sessions occurring on Interchange and the 
students' subsequent writing sessions: 

A full editor allows you to load in text that you've already 
written, or to save parts of the ongoing conversation to a 
file. The students have always had the ability, after a Forum 
session was over, to get the program and call it up and look 
at it. But sometimes it's nice to say, "Well, now, this particular 
chunk, here, I'm going to want later when I'm writing my 
paper." With the new hiterchange, they can take that chunk 
and save it to a file right there, while they're participating 
in the session, and they'll be able to call it up later, (Taylor, 
1989b, interview) 

The hypertext component in the program, completed in March 
1989, came from students' desire to place their new comments 
in those parts of the ongoing conversation where they best 
fitted, as opposed to their only being able to add comments to 
the conversation chronologically as the comments arrived. 

The Daedalus Group members depend on the sale of their 
programs for funding of their software development etforts and 
the continued revision of existing programs. As suggested before, 
this allows them freedom from some of the constraints of grant- 
funded programs like Prose. Because profits from the sale of 
Daedalus Group software can sustain continued development 
efforts, the group has been able to continue revising programs 
in a way that neither Schwartz nor Kaplan has been able to do. 
The company made its first sale in 1989, but survived on a 
combination of capitalization (mostly from friends and family) 
and custom programming jobs for other parties. With the Dae- 
dalus Instructional System now installed at about thirty-five sites, 
sales of its programs have allowed the company to move into 
a four-room office suite on the outskirts of Austin, hire pro- 
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grammers and a half-time administrative assistant, fund a full- 
time position for Wayne Butler, who is completing his doctorate, 
and even pay modest dividends to its shareholders. Butler jokes, 
"I think we surprised even ourselves. I think some of our 
shareholders were investing for the tax write-off" (Butler, 1991, 
interview). The group was able to pay Taylor enough of a salary 
for him to give up his teaching assistantship at the university 
and devote that time instead to program development. 

As a for-profit operation with overhead costs, the Daedalus 
Group has incentive for producing improved, and hopefully 
more marketable, versions of its programs. Indeed, its continued 
success depends in part on Daedalus Group's sensitivity to 
market needs: 

There's something about a free market. I think we were 
much more elitist in the beginning, saying, "This is the way 
we see it needs to be done, and this is the way we'll do 
it," while we remained in isolation with our twenty or so 
students. Now, we're becoming much more sensitive to 
what people want and need and use. . . . There are features, 
for instance, in the new Macintosh version that are very 
sensitive to the market's needs — spell checking, style check- 
ing, all the stuff we pretty much ignored in the DOS 
environment. We've got a concordance maker and some of 
the stuff that is proven and popular; that's what people 
know about computers and English. Well, we need to meet 
them [potential customers] halfway, because they're not 
going to buy the most radical part of Daedalus without 
something they can start with that they already know. 
(Butler, 1991, interview) 

This is a different dynamic than for Prose, for example, which 
was sold by the designers to McGraw-Hill, effectively removing 
from their hands the future of the program. Even though the 
Daedalus Instruction System is being bundled with Helen 
Schwartz's SEEN and William Wresch's The Writer's Helper in 
one of IBM's hardware/software packages, the Daedalus Group 
retains control over the fate of its programs and continues to 
develop and market them on its own. In contrast, Kaplan 
expressed great frustration at McGraw-Hill's failure to produce 
a promised IBM version of Prose, which would have opened up 
the vast IBM-based market for the program. 
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On the other hand, their software development work has 
garnered Taylor and the others no recognition or reward from 
the university or the English department. When asked if he 
received any recognition from the university for his program- 
development efforts, Taylor merely laughed. He then said: 

It would be very difficult to say that I had received any 
formal recognition as a result of that. I have been given 
travel money '.o go to conferences to present papers about 
the software. I presumably would have been given that 
money regardless of what I was going to the conference 
for — whether it was to present about software or Milton or 
anything else. I really cannot say that the graduate program 
has recognized that particular work in any fashion, no. 
(Taylor, 1989a, interview) 

While it might be argued that conference travel is a form of 
reward, Taylor and the other Daedalus Group subjects made it 
clear that they felt the English department, with a few notable 
exceptions, largely saw their interest in CAC work as a nuisance. 
This view is in keeping with the experience of Schwartz, Kaplan, 
and most respondents to the EDUCOM survey. 



Professional Software Development 

Professional software development by private companies like 
Dan Burns's Xpercom take the entrepreneurial approach wholly 
outside of academe. While these design groups operate in similar 
fashion to the Daedalus Group, a key difference is that the 
members of the Daedalus Group are academics, first, and pro- 
gram developers, second; members of professional software 
development teams undertake the task as their sole professional 
pursuit. It is an evolution that is not out of the question for 
some members of the Daedalus Group, as Butler admits, and it 
is a phenomenon common to other disciplines. As such, the 
professional development of software invites brief examination 
for the way it illuminates the entrepreneurial approach. 

Profits from sales of their software must not only sustain the 
development effort of the professional developers, but also 
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provide salaries and all of the operating expenses. Those expenses 
are higher for this design group because it must market products 
more aggressively, produce more polished packaging, and meet 
the support needs of a generally more demanding clientele. 

Because they have usually severed their ties to academe, the 
developers, in this approach, enjoy fewer ties to academic 
research and expertise. While academically based development 
models derive user feedback from classroom use and observation, 
the revisions in professionally developed software are more 
likely to come from customer feedback and market reviews, the 
latter of which can exert particularly strong pressure on product 
revisions. Although software for the academic marketplace is 
reviewed, those reviews are not a prominent part of the journals 
directed to the computers and writing audience. For example, 
Computers and Composition has not includ d many software 
reviews. Academic Computing, which is now defunct, did not 
always include software reviews, and when it did, it buried 
them in the less-often-read first eight pages of the magazine. In 
contrast, the trade publications directed to Ihe corporate sector, 
magazines such as InfoWorld, highlight their product reviews, 
which tend to be lengthy, detailed, and thorough. 

Thoughtline's origins, like so much of CAC software, are rooted 
in the classroom. Dan Burns, the program's sole designer of its 
original versions, was completing a Ph.D. in English (creative 
writing) at Oklahoma State University and teaching composition. 
He also began working for private industry as a speechwriter. 
While interviewing executive clients for the preparation of their 
speeches, Burns found himself using a technique that he also 
used with student writers at the university. He describes this 
method of student conferencing as "directed discussion 77 : 

This was a heuristic technique for helping students develop 
essays by asking questions, challenging assumptions, re- 
quiring supporting evidence, and then critiquing a final 
draft. ... I found that the technique could be applied not 
only to topics that I knew of, but also to topics that I knew 
nothing about. For example, one freshman wanted to do a 
paper on a rock star I'd never heard of. But I could sit 
down with her, ask questions, and stimulate her thinking 
and direct it in such a way that she had something to write. 
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These same techniques I used with students can be applied 
to executive speech writing. (D. Bums, 1989, interview) 

While using this method as a speechwriter, Bums came across 
a 1986 Business Week article that discussed uses of artificial 
intelligence (AI) and its principal programming language, LISP. 

The Business Week cover story — its photo of the scarecrow 
from the Wizard of Oz poised ready to finally get a brain- 
promised a revolutionary future, and Bums was hooked. He set 
out to teach himself LISP: 

For six months, all I did was play with it. I wrote a program 
that would write poetry and Shakespearean sonnets, and I 
wrote one that would write erotic fiction — you know, just 
having fun. And then I began to think about how this could 
be developed for speechwriters. Now, at first, my goal was 
to write a program that would write the entire speech — 
just give it a topic and let it go, a speech machine. (D. 
Bums, ibid) 

Bringing together his teaching experience, his work as a speech- 
writer, and his play with LISP programming, Bums came up 
with the initial design for Thoughtline. 

He soon realized, however, that the idea of a "speech machine" 
was beyond his reach, so he went to work on the more modest 
goal of creating a writing aid, one that would help writers 
develop ideas through a direct-discussion interface. In the de- 
velopment of this first version, Bums operated as a lone program 
developer. His prototype of that program was completed in 
1985, and commercial marketing of the program began in 1986. 
Thoughtline provoked a great deal of interest through reviews 
in PC Week, Executive Communications, The Washington Post 
Manufacturing Week, MIS Week, and a host of other publications. 
Unfortunately, many of the reviews were negative — criticism 
ranged from displeasure with the program interface, to the print 
format, to its mishandling of "to be" verbs — so Bums pulled 
the program off the market. 

Given the sophistication of the program and his early failures, 
Bums knew he needed more technological expertise for a revision 
of the program. He therefore enlisted the aid of AI specialist 
Robert Giansiracusa, a graduate of MIT's Artificial Intelligence 
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Laboratory and an employee of Neurotronics Research Corpo- 
ration, a Washington, D.C, AI development firm. In a ten-day 
marathon session of twenty-hour days, Giansiracusa and Burns 
rewrote the program. In subsequent sessions, the pair changed 
the program interface, switching to easy-to-use pop-up menus, 
adding color, and working on the program's editor to allow word 
wrap. Burns feels, for the most part, that these revisions were 
superficial but necessary for marketplace acceptability and suc- 
cess: 

We found that reviewers will not focus on what I consider 
the substantial points of the program, and they won't take 
it seriously unless it looks like a slick, modern, up-to-date 
program. So it bothered me that our first task was to make 
the program look sharp, which we've pretty much done. 
(D. Burns, ibid) 

In the development of the revised program, Burns and Giansi- 
racusa worked as a team, and in July 1988, the program was 
rereleased as Thoughtline IL 

In the world of commercial software development, the user 
feedback which has the most impact on program revision is the 
published review directed at the target market. Burns discovered 
this early in the development of Thoughtline, when the program 
was released prematurely This time, the program received more 
positive reviews. For example, MIS Week called it a "viable wri- 
ter's tool," and PC Week said, "For the hesitant or inexperienced 
writer, the program offers an attractive approach to combating 
writer's block." At the same time that Burns and Giansiracusa 
were improving the program interface, they were making deep 
structural changes in the program: 

He [Giansiracusa] wanted to write a program that would 
not only conduct a conversation, but that would learn, and 
that would do not only syntactic pattern matching, but 
semantic pattern matching. We're not there yet, but the 
hooks for that are built into the program. We've made it a 
lot smarter than its prototype, and so a program like this 
is never finished. (D. Burns, ibid) 

Indeed, the two developers are continuing to rework the program, 
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trying especially to reduce its hefty memory requirements, which, 
if accomplished, would make it a viable program for that still- 
significant market of microcomputer owners who do not have 
powerful desktop systems. 

Market interest has affected future revision plans for Thought- 
line, as academe had shown some interest in the program. The 
program came out of a business context — Burns's speech-writing 
experience — so its prompts reflect that orientation. Yet Burns has 
been getting inquiries about the product from colleges and 
universities: 

We didn't pay a lot of attention to that market [college] 
because, in 1986, there weren't a lot of IBM compatible 
computers with hard drives and 640K RAM in the colleges 
and universities. And, of course, everybody knows that 
public education is not as well funded as private business. 
They can't write a check for $300 quite as quickly. So we 
thought, "Well, that's fine. If they want to write to us, we'll 
sell to them." (D. Burns, ibid) 

A recent review of Xpercom's customer base reveals that 20 
percent of its sales have been to colleges and university faculty. 
As a result, Burns is considering an academically oriented version 
of the program for the future. 

In contrast to the entrepreneurial model, represented by the 
Daedalus Group, the professional model of program develop- 
ment, represented by Dan Burns, enjoys the benefit of software 
sales in a market that can and is willing to pay a higher price 
for that software. In addition, the professional developer's market 
allows wider technological boundaries in programming efforts, 
given the greater technological resources of the corporate sector 
compared with the average computer writing lab for which the 
Daedalus Group designs its software. On the other hand, the 
business market is, perhaps, a less forgiving one. Professional 
software development is more at the mercy of published re- 
viewers in an aggressively competitive market, while academi- 
cally based development efforts are characterized by greater 
collaboration between users, students and teachers, and the 
developers. 

In both cases, the entrepreneurial model for program devel- 
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opment is marked by the creativity of people who know com- 
position (or who at least have taught a lot of writing) and who 
know programming. Selfe asserts the need for both kinds of 
expertise: 

I would love to have a programmer who knew as much as 
possible about the content area . . . that's why Paul Taylor 
is so good. But there have to be content specialists, really, 
content specialists, not just hackers. English hackers and 
computer hackers — there has to be a blend of the two. 
(Selfe, 1989a, interview) 

Each member of the entrepreneurial design team provides that 
blend; thus, their collaboration provides impressive resources 
for working out problems of pedagogical and technological 
design. In addition, their profits allow them technological re- 
sources not available to faculty designers, who most often have 
to work with whatever hardware is available to them Those 
profits also allow the entrepreneurial design team to operate 
independently of the constraints of institutional funding, and 
because it does not hire outside programmers, the group's 
development costs are significantly lower than those of devel- 
opers who are not programmers. 

The Research-Based Design Team 

At the other end of the continuum from lone programmer 
designers like Mimi Schwartz are the large program design teams 
whose goals are research oriented. These design and develop- 
ment efforts are centered around complex programs constituted 
of multiple subprograms. Often, these programs require ad- 
vanced and expensive mainframe computers and terminals. Such 
efforts are most common in research- and technology-oriented 
universities such as Carnegie Mellon, where they receive sub- 
stantial funding, often from government agencies and private 
industry. The work of John B. Smith of the University of North 
Carolina at Chapel Hill, Christine Neuwirth of Carnegie Mellon, 
and Earl Woodruff of the Center for Applied Cognitive Science 
all follow this model for program design. 
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While program ideas in the other models often arise from 
reflection on classroom practices or from just playing around 
with the computer, the generation of program ideas in the 
research model comes from a highly structured, cognitive map- 
ping of the writing process. These cognitive models are based 
on existing theoretical models and/or original investigative re- 
search. For example, the development of Neuwirth and her 
colleagues' Notes program began with a team member's obser- 
vational research on student note-taking. Neuwirth explains: 

Cheryl [Giesler] did a lot of observational work in trying to 
build up our understanding of what actually went on in 
this task. The notion was to identify problem areas in the 
task for the expert or novice. (Neuwirth, 1989a, interview) 

Or, in the case of their Comments program, they turned to 
research on the way students respond to instructor comments 
on their texts: 

We had an early focus on the users, in which we observed 
people at work, doing the tasks the way they currently did 
them, and then we tried to form an understanding of . . . tried 
to form some representations of that task that we thought 
would be useful. And so it was very empirically researched — 
it tended to draw on the theoretical. We drew on cognitive 
theory, and we drew on the writing process, and we tried 
to pattern what it waf we were seeing. (Neuwirth, ibid) 

In each case, design began with a perceived problem in the 
student writer's cognitive strategies; the programs were created 
to provide "scaffolding" for that part of the composing process; 
that is, the programs are meant to help students through those 
parts of the writing process that researchers have identified as 
being typically problematic areas. 

In the case of Smith's University of North Carolina design 
team, an elaborate multimodal cognitive model was constructed, 
based on a synthesis of research and cognitive models provided 
by Flower and Hayes, Bereiter and Scardamalia, and other 
researchers in cognitive science (Smith & Lansman, 1987, pp. 
5-8). This elaborate cognitive model consists of seven modes, 
each constituted by sets of processes, products, goals, and 
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constraints (pp. 11-12). The model became the system blueprint 
for an ambitious multimodal writing program called WE, a 
program which acts as a writing environment, encompassing 
almost the whole cognitive process of writing as mapped out in 
the design team's initial research and cognitive theory. 

Development of the actual programs in the research-based 
model is conducted by teams of researchers, who often represent 
a number of disciplines. The design team behind Woodruff's 
CSILE program, another "environment" program that seeks to 
encompass the whole of "knowledge building" activities, in- 
cludes people from psychology, education, computer science, 
and cognitive science theory (Woodruff, 1989, interview). At 
Carnegie Mellon, a design team is likely to have two principal 
investigators, a research associate, two programmers, and a 
number of graduate students (Neuwirth, 1989a, interview). Team 
members assume responsibility for various parts of the devel- 
opment process. The same applies to Woodruff's team at the 
Center for Applied Cognitive Science: 

It's [CSILE] a huge program; there are probably over a 
hundred different files associated with its execution. Its main 
heartbeat is the server that manages all user requests for a 
note or for the storage of a note. You can imagine all that 
traffic. That was really carved off and dealt with in a very 
traditional sort of way. We sat down and asked what kind 
of functionality did we need, what would we need to 
achieve that, and then we turned it over to an extremely 
bright CMU graduate, Bob McLean. He took over basic 
responsibility for the server. And it has a nicely defined 
role, and you don't have to worry too much. I mean, either 
it has that functionality or it doesn't, and if it doesn't, you 
fix it. (Woodruff, 1989, interview) 

The complexity of the overall program design and the need for 
each piece of the program to operate smoothly within the greater 
program constrain the development style of those team members 
responsible for pieces of the larger puzzle. One is less likely to 
have the freedom to "play" in the manner described by Kemp 
or Taylor. Neuwirth says: 



I've seen that occur at Carnegie Mellon. Not in our shop, 
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where that really doesn't happen, because I wouldn't let a 
programmer do that [laughs]. Typically, we are the principal 
investigators on grants. That would represent a huge risk 
for us, to have a programmer go off into a closet and maybe 
emerge months later. I don't think I'd feel personally com- 
fortable under those circumstances, the way my existence 
here is constituted. (Neuwirth, 1989a, interview) 

An important reason for not allowing a single team member to 
go too far off on his or her own in the development process is 
the level of user testing typically required at each step of the 
development process in this model 

Not only is there less "play" and formalized delegation of 
responsibility in the research approach to software development, 
but the nature of the team's interaction also differs in dramatic 
ways. First, software development is a primary professional 
responsibility for those involved, and that means interaction is 
a routine part of the work environment (unlike the 11 p.m. 
meetings in Nancy Kaplan's dining room). This interaction allows 
for close collaboration between all team members (no one off 
working alone, as in the Daedalus Group). At Carnegie Mellon, 
for example, Neuwirth housed the Notes team in a suite of oak- 
trimmed offices in Baker Hall, a lovely, old, renovated building 
on the Carnegie Mellon campus. She and David Kaufer, the 
team leaders, the research assistant, the graduate students, and 
the programmers were all situated in the same place and could 
make project discussions part of their daily life: 

We had frequent interactions. We could schedule impromptu 
meetings as well as our usual weekly meeting. Dave is right 
across the hall and we're always bouncing ideas off each 
other. (Neuwirth, ibid) 

While the organization of the research and design team appears 
hierarchal, Neuwirth and Kaufer encourage the team members 
to offer and challenge ideas and decisions. Neuwirth describes 
these sessions as times of creative argument, where ideas must 
be defended vigorously and where people use "every conceivable 
tactic of persuasion known to humankind." She laughingly recalls 
a recent meeting: 

Dave [Kaufer] and I sat down with the programmers and 
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asked, "We want to know whether you believe in this 
programming concept we want to implement?" And they 
hid their faces behind clashed hands— you know, the son 
of church thing where you go, "I do believe!" We regarded 
that as their personal affirmation of faith. (Neuwirth, ibid) 

At the same time that decisions are open to group scrutiny, 
because the team is working on prototype programs, many 
decisions, particularly technical ones, are made informally while 
implementing design goals and may be revisited in later discus- 
sions. 

On another level, this team approach fosters an interplay of 
personalities that, while probably being no more complicated 
than in any other collaborative project, is by virtue of the team's 
size bound to include a wider mix of personality types. The 
team leader in one such group, preferring not to be named, 
complained, "I spend half my day, sometimes, putting out fires 
and smoothing ruffled feathers that stem from conflicts between 
group members." He pointed out that, because such groups tend 
to bring together tenured faculty and graduate students, members 
of different disciplines, academics and hired programmers, con- 
flicts are almost inevitable. For anyone who becomes a chief 
developer on a project, attention to personal dynamics can be 
a challenge. Neuwirth, who confesses to being painfully shy, 
realized on one project that her position as project manager 
required her to assume a "booster role." Therefore she read 
management books that described motivational, techniques and, 
she says, "I'd study these things and try them. It was something 
that didn't come naturally to me" (Neuwirth, ibid). Those 
challenges aside, the creative-collaborative energy of the research 
design team, though quite unlike the playful creativity of the 
Daedalus Group, for example, is indeed one of the major 
strengths in this model. 

The user testing that takes place here during program devel- 
opment is a much more elaborate process than the informal 
observation of program use described in the other development 
models. The more formal and fundamental integration of user 
feedback is called "participatory design." This approach includes 
user testing from the program's inception, in the way Neuwirth 
described their study of student note taking, through each 
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revision of the program, through formal field testing. Woodruff's 
team members installed their first version of CS1LE in a public 
school, where they received feedback from teachers and students. 
However, in contrast to Neuwirth's team, they validated this 
more informal feedback with protocol studies of selected stu- 
dents. He explains: 

At that point, we started tracking twelve students — meeting 
with them every week for an hour — trained them to think 
aloud, and they became fairly comfortable with this study 
And we studied whether the system was helping them or 
hindering them, and how we could change it in response 
to that. At that time, then, the program was changing about 
every six weeks. (Woodruff, 1989, interview) 

User feedback and study not only prompted design changes, 
they also informed the actual shape of those changes: 

We would sit down with the kids and mock it up [a design 
change] with paper and pencil, trying to see if that was a 
reasonable way to go about it. We would sit and watch 
them move pieces of paper around a desktop, trying to 
simulate the types of connections they were trying to make 
between pieces of information, and then build, design, a 
system that would accommodate what they were trying to 
do, with what we were fairly certain they probabi ; should 
be doing. And then write that up in code and start following 
that along with case studies . . . Then from time to time we 
moved to full-class studies, much larger studies. (Woodruff, 
ibid) 

While the research goals and resources of design teams in the 
research model allow for extensive rewriting of programs, there 
comes a point in program development when the bulk of those 
revisions is complete. At that point, the team members can focus 
their research efforts on field testing of the program to explore 
the viability of their original goals. 

Perhaps the most ambitious example of such testing is that 
which is being designed for Smith's WE project. Smith's group 
included an automatic tracking function in the design of WE 
which produces a detailed transcript of a given user session. 
That transcript records each action performed by the user, as 
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well as its time and other important structural information, such 
as the location of nodes on the user's program-generated outline 
(Smith & Lansman, 1987, p. 17). Smith claims that "these data 
avoid one of the most serious problems posed by think-aloud 
protocols — i.e., distortion of the user's cognitive processes" (p. 
17). The protocol data can be used with a session replay program 
that allows for the reproduction of the session, unfolding in 
time, and that can be speeded up or slowed down as the observer 
wishes. Writers can be asked to observe their own session 
replayed and to comment on their thinking and intentions for 
various actions or sequences (p. 18). Currently under develop- 
ment is a "grammar" for parsing the protocols. This grammar 
would have five levels of functionality. In essence the grammar 
would 

1. Offer a symbolic representation of the protocol transcript 
produced by the tracker. 

2. Take those symbols and map them onto a more abstracted 
symbol system that would identify operations, such as the 
create node described in their cognitive map. 

3. Map these onto a third level of symbols representing 
intermediate products, such as isolated concepts, relations, 
structures, blocks of text, and so on. 

4. Infer the cognitive processes used by the writer to construct 
these products, processes such as recalling ideas from 
memory, associating them, or encoding them linguistically. 

5. Infer the cognitive mode the writer is inhabiting at a 
particular time, such as exploring, organizing, or structural 
editing. (Smith & Lansman, 1987, p. 18) 

Smith argues that the tracking functions of WE address many 
of the well-documented problems through the use of think- 
aloud protocols. As mentioned above, he argues that the tracking 
function avoids the cognitive distortion problem commonly 
associated with think-aloud protocols. The grammar would also 
solve the problem with inconsistent protocol generation and 
analysis, in that all the actions of the writers are recorded and 
the grammar offers objective analysis of the data (p. 18). With 
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the computer doing so much of the work, Smith believes 
researchers can work with much larger numbers of protocols 
than before. 

As one might guess, the technical sophistication of programs 
like CSILE, WE, and Notes requires hardware and software 
resources usually available only at large universities. They need 
the memory and speed of large mainframe computers and the 
screen size of workstations like the SUN 3. This type of hardware, 
the size of the design teams, the amount of programming 
involved, and the degree and kind of testing involved in the 
design effort make the research design and development model 
very expensive. None of the subjects interviewed would divulge 
their project budgets, though Smith spoke in terms of $450,000 
budgets for development projects (J.B. Smith, 1989, interview). 
These kinds of funds are likely to come from a combination of 
government and corporate funding agents, yet the subjects were 
mostly reluctant to reveal those sources. When asked about the 
funding sources for CSILE, for example, Woodruff said, "I can 
tell you that there are many. There are seven, but I can't tell 
you the people who are involved" (Woodruff, 1989, interview). 
He did say that they included both corporate and educational 
sources. Funding sources for WE are identified in the project's 
technical reports and include the National Science Foundation, 
the Army Research Institute, and IBM. The home institutions 
for these projects may assume some portion of the funding but 
are more likely to cover overhead costs such as hardware. 

While the home institutions provide only a small portion of 
the development funds, they do tend to provide a reward and 
incentive structure that encourages participation in such program 
development efforts. The Center for Applied Cognitive Science 
offers release time to program developers. Neuwirth says Car- 
negie Mellon treats software development as they would pub- 
lished research: 

I don't think Carnegie Mellon would provide any sort of 
reward, promotion, or tenure for a program that essentially 
implemented yet another text analyzer, only in SNOWBALL 
rather than PASCAL. It's held to the same standards [as 
traditional research]. I am one of the few people who is a 
junior person actually building software tools, and my 
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renewal case went through, and that work was acknowl- 
edged as contributing to my case. And so, it was supported 
at the department, college, and university levels. (Neuwirth, 
1989a, interview) 

These developers enjoy a level of recognition and reward not 
reported in any other model of program development. 

To review then, the research-based design team model of CAC 
program development is most likely to take place in a research 
university with access to the technological and funding resources 
necessary to such a design model. The development effort is 
conducted by a large, often interdisciplinary, design team that 
follows a highly structured design protocol that includes exten- 
sive user testing throughout the development process as well as 
after installation of the program in the classroom or computer 
writing lab. The programs that emerge from this model are likely 
to be based on cognitive theories of the writing process and 
may try to account for most, if not all, of that process in their 
design. 

As Doheny-Farina and Odell (1985) point out, the "present" 
that the ethnographer discovers is not static. It is subject to 
change, even as it is being described (p. 530). This could be no 
more true than in the world of CAC software design, for the 
developments of new technology continue to create new pos- 
sibilities for software, almost every day. Innovations such as 
hypertext, object-oriented programming, and Al-based authoring 
languages open up new doors in the design of new programs 
and the redesign of existing ones. In addition, the issues of 
funding, the role of software development within departmental 
reward structures, the marginality of CAC specialists within the 
field of composition, and a number of other factors are impacting 
the models just described. The next chapter explores these forces 
of change in CAC software development and their implications 
for the future of program design. 
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Forces That Impact 
CAC Software Design 

It becomes evident in the discussion of development models 
that a wide range of factors influence any given development 
effort and thus the program which emerges from that effort. As 
was seen in the case of Prose, the way the program was 
developed, revised, and ultimately used had a lot to do with 
factors such as funding, technological constraints, and Cornell's 
treatment of the design effort. The idiosyncratic nature of each 
program's development was illustrated again and again in the 
development histories of the programs examined in this study 
For example, the fact that James Berlin taught for one year at 
the University of Texas and greatly influenced Fred Kemp and 
Wayne Butler, who then provided a strong theoretical influence 
on Taylor's development of Interchange, is a project-specific factor. 
That said, a number of forces were repeatedly cited by the 
interview subjects as having either an immediate or a forthcoming 
impact on software design. In this section, those primary im- 
pacting forces will be considered. 

While the previous discussion identified the various ways that 
writing software tools are built, this discussion will examine the 
forces and issues with which the tool builders must grapple in 
their respective models. The interview subjects identified three 
primary influencing forces in CAC development: technology the 
reward and recognition systems of institutions and English 
departments, and funding. By examining these three forces as 
they exert themselves upon the CAC design and development 
continuum, both now and in the future, one can begin to 
determine the kinds of software tools that will be available to 
writers and teachers of writing and to raise questions about the 
implications of these tools for the field of composition. 
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Technology 

CAC program designers are faced with a number of choices 
in the development of their programs. What kinds of tools will 
they use to build their programs? What capabilities do they want 
their programs to include? What technological innovations seem 
available and reasonable to include in their program's final 
shape? By and large those choices will determine a given 
program's substantiation, how it will be used, and who is likely 
to use it. For the interview subjects, the most important tech- 
nological forces are or will be: 

programming languages; 

system architecture; 

networking and telecommunications; 

CD-ROM; and 

artificial intelligence (AI). 

As Paul Taylor says, "What we are able to do will always be 
determined by the hardware and, in fact, the programming 
languages we have available" (Taylor, 1989a, interview). Most 
CAC developers do not have the funds to begin a development 
effort by purchasing new hardware and software. This can even 
be true for well-funded research design programs. Instead, most 
CAC developers work with whatever is available to them at 
their institutions. So, for example, if the University of Texas 
Computer Research Lab had been given unnetworked Macin- 
toshes instead of networked IBMs, Taylor would not have written 
Interchange. What software developers eventually end up with 
has as much to do with the technology they begin with. 

Programming Languages 

As was illustrated in the earlier accounts, the need either to 
learn programming or to hire and collaborate with programmers 
remains a considerable obstacle for writing teachers who want 
to develop software. Mimi Schwartz, for example, has considered 



68 



Writing Teachers Writing Software 



developing a revision program to complement Prewrite, but cites 
the challenge of finding and working with good programmers 
as a primary reason for not doing so (M. Schwartz, 1989, 
interview). However, there was general optimism among the 
interviewees regarding improvements in programming lan- 
guages, particularly in the development of authoring software 
that would allow them to develop sophisticated programs with 
much less training in programming. The two primary develop- 
ments allowing for such progress are object-oriented program- 
ming (OOP) languages and hypertext software tools. 

Object-Oriented Programming 

Object-oriented programming (OOP) is not new. It has been 
used in research for over fifteen years, known best as "data 
abstraction/' but improvements in memory and processing speed 
are making OOP viable for microcomputer applications. Selfe 
says, "I think object-oriented programming languages are going 
to open up programming to nonspecialists" (Selfe, 1989, inter- 
view). OOP languages offer a fundamental and efficient alter- 
native to traditional programming languages through their sub- 
stitution of "objects"— blocks of reusable and easily transportable 
programming code — for the thousands of lines of code necessary 
to create functions in languages like FORTRAN or COBAL. 

As a design concept or methodology, object-oriented program- 
ming attempts to make programs operate more like the human 
mind, at least as the human mind is understood by researchers 
such as Marvin Minsky or Philip Johnson-Laird. The objects in 
object-oriented programming are like Minsky's "frames," cog- 
nitive data structures that define stereotypical situations which 
the human mind then combines in order to understand the 
world (Minsky, 1981, p. 95). Minsky argues that the mind does 
not have to work through the extensive lines of definition that 
form a situation. Instead, it possesses frames, which consist of 
"default values," blocks of possible responses to external stimuli 
(Johnson-Laird, 1983, p. 189). The mind, when confronted by 
problematic stimuli, can combine various frames until the ex- 
ternal situation is satisfactorily defined. That new definition can 
then become part of the mind's storehouse of frames. The more 
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default values with a frame, the more finely tuned the frame 
can become in response to a situation. 

To illustrate, consider a small child learning to name things 
in its world. Assume it has a frame for "bug/' for which the 
oc'ault values include "six legs, slightly round body, walks on 
the ground, smooth shiny torso, pretty quiet," Another frame is 
"airplane," for which the default values are "a shape that is 
long and crossed by another straight part, moves through the 
air, and is pretty quiet." The child sees a butterfly for the first 
time and shouts "airplane-bug!" In the naming of the butterfly, 
the child has created a new data structure, or frame, finding in 
the butterfly some default values of the frame "bug" and some 
default values of the frame "airplane/' and has combined the 
two to create a new frame, "airplane-bug," which combines 
characteristics both of form (shape, legs, shiny torso) and of 
function (flight). 

Rather than creating programs through infinitely lower levels 
of definition, object-oriented programming employs reusable 
elements, or blocks, comparable to frames in this analogy. Each 
block of code, known as an "object," is a set of definitions and 
functions, the default values of Minsky's frames. They can be 
recombined in a number of ways to create new "objects," which 
then become part of the program's library of objects. The two 
key characteristics of object-oriented programming are the com- 
bining of data and function and the use of flexible code modules. 
Jane Fitz Simon (1989) explains the former: 

Imagine you want to add together two numbers. In tradi- 
tional computing, you call up the operation "plus," feed in 
two numbers, and run the operation. With object-oriented 
programming, instead of calling up the "plus" operation, 
you call up a number "X," and send it a message, "Add Y 
to yourself." The data is already imbued with the ability to 
carry out the command. (A4) 

Data structures that combine form and function remove a whole 
level of program functionality from the developer's concerns. In 
addition, authoring languages designed with the object orien- 
tation offer the user blocks of code. These blocks of code would 
make up objects that could be used in a variety of combinations 
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to solve problems or to write programs without the programmer 
having to write code line by line (Simon, 1989, Al). The 
advantages to the program developer are that the objects always 
remain the same and are therefore reusable; that they are highly 
reliable and maintainable; and that they save a great deal of 
programming time. Parlett is working on a design for this type 
of authoring system, one which would allow users to create 
Confer programs for any given piece of text they desired. 

While object orientation holds great promise, it has its draw- 
backs. Very practical concerns are the high processing speed and 
the great amount of memory required to run a program designed 
with object orientation. When the computer runs such a program, 
it must process each object in its entirety, even though only one 
or some of the default values within the object are being called 
upon. 

Reconsider the airplane-bug example. For a computer to 
replicate that child's creation of a new frame, it would process 
the default values in the "bug frame" that apply to the new 
object it is trying to name, the butterfly in question. The default 
values of six legs, slightly rounded body, and shiny torso would 
obtain, but it would also process and reject the characteristic of 
walking on the ground. With OOP, the computer processes 
needless default values. In contrast, a conventionally designed 
program would precisely define butterfly, and then the computer 
would process only that information. Expand this simple example 
to the world of complex computer programs, and what happens 
is that programs designed with object orientation have much 
slower throughput, the speed at which a computer can process 
program code. OOP enthusiasts argue that processing speed will 
catch up with the software. 

One other concern about object orientation is the question of 
refinement in program design. Because OOP designed programs 
reuse objects, recombining them and creating new objects, the 
programs are employing elements not necessarily designed for 
their specific programming tasks. To illustrate, imagine we were 
designing a computer that could play racquetball. When we 
work on the part of the program that effects a backhand shot, 
we know that we need to program in the slight upward turn, 
or twist, of the racquet in the hand. Using an OOP approach, 
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we would look through our library of objects and find one that 
defines the general action of wrist turning, and within that 
object there would be a series of defining defaults. Included in, 
perhaps, a long list of default values that define the turning of 
the human wrist, we might find what we need to effect this 
action, so we employ the object in the backhand subprogram 
we are working on. We have saved a lot of programming time, 
because we have not had to write code line by line to effect 
this movement. However, by writing the code ourselves, we 
could define a more subtle turning of the wrist — a more finely 
tuned action. In other words, we can effect a turning of the 
wrist that is exactly where it should be instead of the close 
enough position we might get with a preprogrammed block of 
code. 

If the promise of object orientation is fulfilled, it will have 
the general effect of producing more high-quality, reliable, and 
easy-to-maintain software at a lower cost. For CAC development, 
this could reinvigorate software design by lone faculty program 
developers and small-group developers in a number of ways. 
Once these developers got over the hurdle of learning an OOP 
language like C++, they could develop programs much more 
quickly than they could with programming languages such as 
Turbo Pascal or Prologue. In fact, some experts argue that people 
with little or no programming experience comprehend the con- 
cepts behind OOP more quickly than experienced programmers. 
A development expert for Asymetrix Corporation, John Wood, 
says, "The initial learning time seems to be quicker for people 
who have never programmed before" (Johnston, 1989, p. 25). 
Or, if they continue to work with hired programmers, they could 
get a lot more programming for their money. In both cases, the 
quality of programs would be higher in terms of standardization 
(and thus reusability in other programming efforts), reliability, 
and debugging (a potentially laborious process in conventionally 
designed programs). 

Authoring programs, the design of which OOP makes much 
easier, would offer powerful development tools to faculty de- 
signers. Authoring programs give nonexpert programmers all 
the building blocks for designing a program, and allow them to 
construct these programs without a lot of technical language or 
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expertise. For example, an authoring program for Farlett's Confer 
program (which only works with Walker Percy's "The Loss of 
the Creature") would give an instructor the basic structure of 
the program and allow her to gear it to any work she wishes 
without rewriting the code. In any case, object orientation, and 
the authoring systems that may derive from it, could stand to 
empower classroom teachers for the creation of their own 
sophisticated CAC software, in the same way that BASIC led to 
a generation of early CAI programs ten years ago. 

Helen Schwartz believes that creating software has to become 
as easy as authoring a textbook before writing teachers can 
undertake the task in significant numbers. She believes that 
authoring programs may be the answer: 

It's fairly easy to publish your own textbook. [Publishers] 
have reps beating the bushes looking for people to do it. 
They [textbook publishers] have got it down so that pro- 
ducing a textbook is not very difficult or very expensive. 
Developing software is not cheap, and it is not easy. If it 
[creating software] can be made as cheap and easy as writing 
a textbook, it can work— and you can do that with proto- 
typing or authoring systems. (H. Schwartz, 1992, interview) 

She points out that these programs may not allow novice 
developers to do everything they would like to in a program, 
but as she says, "They're a heck of a lot easier than learning 
programming." Hypermedia authoring systems are beginning to 
reinvigorate faculty-based software development, though they 
have not yet achieved the ease of use and the affordability that 
Schwartz cites as being necessary for widespread faculty devel- 
opment of CAC software. 

Hypermedia 

In terms of programming languages and authoring systems, 
hypertext and hypermedia software development programs de- 
mand special attention. (While the former term enjoys currency, 
the latter is more accurate, since almost no hypertext system 
exists which does not include nonprint media.) Hypermedia is 
drawing particular attention from CAC researchers because it so 
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profoundly challenges the conventions of print-based literacy 
practices. Moreover, and more germane to this discussion, hy- 
permedia systems are significantly easier to use and allow 
nonprogrammers to create highly complex programs. As such, 
these systems address one of the major hurdles to faculty-based 
software development: the cost and complexity of writing the 
actual program code. As William Wresch says, "The more 
transparent you can make the technology, and the lower you 
make the development threshold, then the more people will be 
willing to spend their nights and weekends developing this stuff. 
I think that will be the trend" (Wresch, 1992, interview). 

Hypermedia, a term developed from Ted Nelson's original 
coining of "hypertext," describes "the synthesis of diverse forms 
of information storage and display based on a single computer 
program" (Beck & Spicer, 1988, p. 220). One of the main features 
of hypermedia is the nonlinear linking of information, any 
information that can be digitalized, without altering the original 
data structure from which that information is taken. The units 
of information within a hypermedia document or application 
are called "nodes." A node can be a piece of text, a movie clip, 
a song or musical passage, a photo image, or a combination of 
media. Nodes can have multiple electronic links to each other 
and allow potentially endless paths through the data as a whole. 
The boundaries between information types are broken down, 
and the hypermedia environment gives the user a great deal of 
control in how she wishes to link that information. 

The most popular hypermedia program in CAC software 
design has been Apple Computer's HyperCard, designed by Bill 
Atkinson and released in 1987. The program includes a flexible 
integrated text/graphical database system, an interpreted close- 
to-natural-language programming language to operate the hy- 
pertext functions, and built-in program features that allow users 
to make links without having to know the programming that 
effects those links. Such functionality makes possible the creation 
of highly complex applications (at least from a programming 
standpoint), but requires little experience or training to use. Beck 
and Spicer (1988) report an average learning time of sixteen 
hours for novice faculty working with HyperCard (p. 24). There 
are many hypermedia authoring systems now available on the 
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market including Guide (which actually preceded HyperCard), 
StorySpace, Folio, VIEWS, Supercard, HyperWord, HyperWriter, 
HyperTies, and ToolBook. Such systems are already finding wide 
use in technical writing, and their proliferation is reflected in 
their sales: $1.6 million in 1987 and $485 million projected for 
1993 (Fersko-Weiss, 1991, p. 242). 

In CAC software, hypermedia, but mostly hypertext, is be- 
ginning to establish itself. The hypertext component in Inter- 
change, for example, has addressed one of the most common 
complaints among users of the program: that "lines" of con- 
versation were difficult to trace because of the first-come first- 
served structure of the main conference. Now the main con- 
versation not only builds in a linear fashion as comments are 
added on to the end, but also within itself as new comments 
are linked within the main conversation. 

Anne DiPardo and Mike DiPardo are designing a HyperCard- 
based CAC program that would allow students to write essays 
with built-in buttons which open up windows that would include 
the students' asides, further explanations, and other information 
they wish to link out from the text. In addition, the stacks (the 
name given to information structures linked out from the surface- 
level text in a HyperCard document) would include help screens 
and exercises to help guide students through assignments; a file 
of pictures to help spark brainstorming; a note-taking function 
that can be referenced later; an extensive file of sample essays, 
with voice recordings of their authors describing their composing 
processes; a peer communication function; and an instructor/ 
student messaging function (DiPardo & DiPardo, 1989, p. 30). 
Donald Ross (1989) imagines hypermedia text programs that 
will allow students to integrate other media in the creation of 
their documents: 

We will be able to include visual and sound images and 
music into our assignments, and expect them to be part of 
the students' writing. These will not just be "figures" or 
illustrations, but an integral part of the presentation. In 
effect, then, the student will be producing a multi-media 
narrative and commentary, (p. 74) 

Aside from the obvious design possibilities suggested in the 
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previous examples, the relatively low cost of hypertext devel- 
opment, and even hypermedia development, allows its integra- 
tion at all points along the design continuum. 

While hypermedia authoring programs have the potential to 
reinvigorate faculty-based software development in the lone 
programmer and small-group models, it will still be some time 
before their full impact is felt. Hypermedia systems are still 
relatively expensive, though an increasing number of "multi- 
media" systems are being announced (though merely adding a 
CD-ROM drive to a PC does not make it a hypermedia system) 
and the computer industry is decreasing the costs for its products 
at an unprecedented level. More importantly, there are significant 
technological hurdles to overcome. Storing video clips, for ex- 
ample, requires huge amounts of hard disc space (three minutes 
of uncompressed video requires about 90 megabytes of hard 
disc) and makes networking expensive and difficult. The current 
state of the hypermedia market is chaotic, with new products 
and support systems being announced almost weekly but with 
little standardization among manufacturers. While computer 
technology has always posed the risk to consumers of nearly 
immediate obsolescence in any purchase (remember those $4,000 
Apples with 64K of memory), hypermedia technology is partic- 
ularly volatile in this early stage of its development in the 
microcomputer environment. Advances are being made in 
compression technology and network transmission speeds, sup- 
porting hardware is improving, and industry attempts at setting 
standards are under way. Jrhn Manzelli, technical director for 
multimedia development at networking giant Ungermann-Bass, 
says, "In about three years the industry will have reached a 
stage where software producers can reliably know what they 
will be working with. When that happens, we'll see an explosion 
of hypermedia software and applications" (Manzelli, 1991, in- 
terview). 

While there is little actual hypermedia CAC software on the 
market, the impact of the technology has been enormous. At 
conferences and in computer and writing journals, hypermedia 
is one of the most discussed and lauded developments in CAC 
software design. Robert J. Beck and Donald Z. Spicer (1988), of 
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Dartmouth University's "HyperTeam/' feel that hypermedia will 
revolutionize software design: 

Designed for easy handling of multimedia, HyperCard has 
been presented as the harbinger of a new dawn of software 
engineering by and for the masses. It is a forerunner of so- 
called "authoring tools" which enable users, other than 
professional programmers, to design and implement their 
own information organization and presentation applications. 
The rapid prototyping and development possibilities avail- 
able with HyperCard suggest that it and similar products to 
follow will spark a renaissance in educational software 
design, (p. 23) 

And unlike the promise of so many hardware and software 
advances, which await development of just one more piece of 
hardware or one more piece of software, hypermedia is on the 
doorstep now. 



System Architecture 

Most often, the computers that developers find in their labs 
are IBM PCs, Apples, or Macintoshes, none of which share a 
common system architecture. In each case, the system architec- 
ture demands different design characteristics in software. Taylor 
discovered this when he attempted to use a Macintosh to program 
a simple grammar tutorial he had written for the IBM: 

If I developed an exercise that had to do with pronouns, 
in my ideal version of the exercise, the main loop of the 
program would say, "What are we going to do next," and 
when the main loop says, "We're going to do the pronoun 
exercise now," that was called up. I knew that my program, 
my section of code, had complete control over the program 
and the computer at that point. I started at the beginning 
of my section and proceeded until something was keyed 
which said either they quit, or they finished the exercise, 
or whatever. But I knew that the whole time, I was in 
control of the program. The Macintosh has what they call 
an "event-driven philosophy." Rather than saying we're 
going to set up this sequence of events that are going to 
happen, like in the IBM, I can't predict everything that's 
going to happen. 
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[In the IBM] I ask for an answer and I don't know exactly 
how an individual is going to answer, but I know that after 
that, we're going to move on to the second question and 
the third question. In the Macintosh, they have tried to give 
the user as much flexibility as possible, so that you can be 
in the middle of running your program — the student can 
be sitting there doing a tutorial on pronouns — and just 
pause, right in the middle of that, and go over and click 
on an icon that brings something else up. (Taylor, 1989b, 
interview) 

There are other illustrations of system architecture's impor- 
tance. Because Interchange was developed on the IBM, Taylor 
was unable to design it so that the user could see multiple 
conferences at the same time. On the IBM, the user can participate 
in multiple conferences, but must jump from one to another. 
This would not have been the case if the program had been 
designed for the Macintosh: 

Now this [the inability to view multiple conferences] is 
primarily a constraint of the operating environment itself. 
This is the way that, well, what I'm thinking of is the 
difference between an IBM PC and a Macintosh. A Macin- 
tosh i 5 set up to handle windows and is designed that way. 
The IBM really is not. (Taylor, ibid) 

However, had Taylor designed Interchange for the Macintosh, 
he would have undercut the program's usefulness as a networked 
communication program: 

So far, Mac networking has lagged behind that of IBM. I 
think that they are catching up. But IBM PC networks are 
currently operating faster and more efficiently than networks 
on Macintoshes. This kind of program is extremely de- 
manding on a network. You have to have one that works 
very quickly and efficiently. (Taylor, ibid) 

Developers of CAC software are faced with a host of these kinds 
of trade-offs and decisions. 

Even developers who possess considerable expertise and abun- 
dant technological resources work within technological con- 
straints. Neuwirth illustrates: 
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Wp haven't reached the point yet where memory is so good 
that we don't have to worry about it. I can give you some 
instances ... In our own work, in the Notes program, we 
had a serious trade-off between, on the one hand, being 
able to bring up a note at an unacceptable rate of speed 
and put it in its own window, which gave the writer more 
flexibility in terms of placement, and, on the other, giving 
it its own shape and size, and things like that. We would 
have liked to had the best of both worlds. We were working 
with the current memory of the machine, which was 1 
megabyte I think. When user testing, we decided that the 
speed at which it came up was far more important — that 
the whole thing just wasn't going to fly if we couldn't bring 
up a note card as quickly as you could in a file index sort 
of thing. That was definitely a trade-off due to hardware 
limitations that we were banging our heads up against. 
(Neuwirth, 1989a, interview) 

Because the graphics capabilities (for example, the ability to 
move and shape the notes windows) use large amounts of 
memory and processing speed, Neuwirth's design team had to 
compromise in the program's design and preserve the program's 
pedagogical integrity. 

While the technological constraints that a Schwartz or a Kaplan 
face are most often based on the computers their students are 
working with in the lab, the constraints that the research design 
teem faces, and the choices they make to overcome those 
constraints, may greatly increase the lag period between rhe 
development of their programs and their widespread use in 
computer writing labs. This is largely due to the fact that the 
way to overcome many technological constraints is through more 
expensive hardware. To illustrate, consider Smith's WE program. 
Because it is a multimodal hypertext program that allows move- 
ment through simultaneously displayed windows, it demands a 
very large monitor screen (as well as computing speed and 
memory). As a result, the program has been designed to operate 
on the Sun Microsystems SUN III, a powerful workstation with 
a 20-inch screen. The funds for five SUN Ills would cover the 
hardware and software expenses of a thirty-workstation IBM 
lab, a trade-off that most writing programs could not afford. 
Therefore, programs developed by someone like Kaplan might 
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face technological limitations, but they can be widely used by 
student writers; programs like Smith's, on the other hand, can 
overcome their technological limitations, but in doing so, create 
limitations in their dissemination and use. 

Indeed, even though the cost of memory and faster central 
processors has continued to decrease, programs are becoming 
increasingly complex, with the use of color, graphics, hyper- 
media, and networking capabilities making heavy demands on 
memory and processing speed. An extreme example would be 
Parlett's Confer program, which was actually scaled down for 
microcomputer use, but at that time which still required 18 
megabytes of hard-drive storage, a then very fast 386 processor, 
and at least 3 megabytes of RAM. Or, if one wishes to include 
IBM's Interleaf Publisher, a premier desktop publishing program, 
in his or her software library, one would need a 386 machine 
with 6 megabytes of RAM. To use ToolBook, one should have a 
486 system, 6 megabytes of RAM, and a very large hard drive 
to accommodate the program, the Windows operating system it 
requires, and the applications one creates with the program. 

Unfortunately, none of the interview subjects were very op- 
timistic that these hardware constraints would be addressed in 
the near future. There was general agreement that screen size 
would continue to be a problem for some time to come; that 
memory woulc continue to be more affordable, but still a 
development constraint as programs become more complex; and 
that while IBM's licTv OS2 operating system seems to suggest a 
convergence with the Macintosh system, the lack of standard- 
ization will, most likely, not be rectified very soon. While the 
Apple and IBM partnership agreement of 1991 holds some 
promise for the future, skepticism runs deep among both CAC 
specialists and industry experts. 

Networking 

While there are numerous networking systems, all of them 
effectively do the same thing, which is to link individual work- 
stations so that they can transfer and share information. Two 
things have happened to make networked application software 
more interesting to CAC program designers: (1) the decreased 
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cost of memory and processing speed has made the networking 
of computer writing labs a more affordable proposition; and (2) 
the growing influence of social epistemology in composition 
theory has moved CAC researchers to explore the ways in which 
networking can facilitate collaboration. Local-area networks 
(LANs) are not new, but the expense in the past has made them 
more feasible for the corporate world than for academia. Collier's 
1987 study, "Computer Writing Facilities: The State of Art" 
(Collier, Gerand, Parbs, & Morrison, 1987), asked respondents 
how they would upgrade their systems, but networking did not 
show up in the responses (pp. 11-12), even though a later 
question revealed that 75 percent of the respondents considered 
networking desirable, while the other 25 percent conceded its 
future value (p. 35). One of the primary reasons listed for not 
networking was expense (p. 35). Now that LANs are more 
affordable even for small schools, there is growing interest in 
how to use them in the writing class. Writing teachers have 
discovered the efficiency of disseminating information, the shar- 
ing of files for peer-editing, and the use of electronic mail 
(usually a standard part of the networking software) to facilitate 
communication between instructors and students. 

Those fairly straightforward uses of networks have sparked 
the interest of CAC program designers. There now exists a small 
number of first-generation CAC programs designed to take full 
advantage of networking capabilities. Taylor's Interchange pro- 
gram, along with Trent Batson's ENFI system and Xerox Palo 
Alto Research Center's Colab tools, allows for real-time conver- 
sation on the network. As explained elsewhere, these programs 
allow for on-line class discussion and can display source texts, 
including student texts, as that discussion takes place. CS1LE 
uses networking to create a classroom database in which all 
students' notes in all CSILE sessions can be saved to create a 
growing database of community-constructed information. For 
example, if a class is reading the same article and will write a 
response to it, individual members of the class can access the 
database to see what their peers have been thinking and saying 
about that article. At one field-test site, two classes contributed 
over 12,000 notes to the database (Woodruff, 1989, interview). 
Neuwirth's Comments program allows a student to use any 
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workstation on campus to send a paper to another student or 
to an instructor, to get it back with comments, and then to make 
comments on the comments, and subsequently to begin a 
dialogue with the original recipient if both parties wish to pursue 
the dialogue further (Neuwirth, 1989a, interview). 

A related technology to networking, and one often used in 
conjunction with it, is telecommunications. Computers can com- 
municate with one another through the use of a modem, the 
price of which has come down to under $100 in some cases. 
Modems allow networks to exist over large geographical spaces. 
This means that a student can participate in an on-line writing 
class from home or that an instructor can access student texts 
from an office or home study. Modems facilitate the formation 
of electronic classrooms without spatial limitation, as with 
BreadNet students in a New York suburb, who spent a semester 
working with their peers on a South Dakota Indian reservation 
by using telecommunications (Selfe, 1990). This technology is 
in place and needs to be examined for the ways it might be 
integrated into CAC program design. 

CD-ROM 

CD-ROM, which stands for ''compact disc-read only memory," 
is a storage medium capable of holding vast amounts of infor- 
mation. The compact disc, best known as a medium for the 
digitizing of music, can accommodate a far greater amount of 
digitized information than the conventional hard drive. One 
compact disc, for example, can hold the whole of the Oxford 
English Dictionary. Because it is "read only," the information 
contained on CD-ROM can be accessed but not altered by the 
casual user. As a result, it can become an increasingly important 
way to store archival information, and it is seeing increased use 
in libraries. Indeed, Laub (1986) reports that "CD-ROM, intro- 
duced early in 1985, is already the heart of some serious 
businesses based on electronic publishing of encyclopedias, 
reference works, professional directories, and other large data- 
bases" (p. 161). 

Now that archival information can be stored more easily in 
digitized form, program designers are interested in the ways in 
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which they can give their programs access to this information. 
Robert Alun Jones's Hypermedia Learning Lab, at the University 
of Illinois at Urbana-Champaign, is using CD-ROM to support 
its networked Macintoshes with a growing library of application 
software and data files (Jones, 1988, p. 24). The Brown University 
Library catalog is being converted to CD-ROM storage — now 
350,000 records with about 20,000 additional records being 
converted every month — and is available to any workstation on 
campus through the campus-wide network, BRUNET (Hawkins, 
1989, pp. 37-38). The prospect of including program access to 
archival information is an appealing one for CAC developers. 
Dan Burns cites it as one of the major development goals for 
future versions of Thoughtline: "With an $85 modem, the user 
could plug into a database and carry on a conversation, and not 
just with his own subconscious processes, but with an entire 
range of authors and their works — millions and millions of 
articles" (D. Burns, 1989, interview). 

While CD-ROMs are not yet common to computer-based 
writing environments, their price has plummeted as new mass 
storage media have been announced. Compact Disc-Write Once, 
Read Many (CD-WORM) and Compact Disc-Read Write (CD- 
RW) drives are on the market and will allow for much more 
flexible use of CD technology as a storage medium (and go far 
in solving the storage demands of hypermedia and other appli- 
cations that use sound and video). Optical storage devices are 
also available, introducing unprecedented storage capacity, and 
while the cost of these newer technologies is still prohibitively 
high for most writing environments, there is no reason to believe 
that they, like all earlier computer technologies, will not become 
more affordable. 

Artificial Intelligence 

Artificial intelligence (AI) is perhaps the most ambitious goal 
of computer research. For some it conjures up images of Fredkin's 
"super-machines," which hardly deign talk with humans (John- 
son, 1987, p. 30); however, a more reasonable sense of AI is 
suggested in its only slightly more modest goal, articulated by 
Minsky, of "making machines do things that would require 
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intelligence if done by men" (Boden, 1977, p. 4). In educational 
applications, one might rephrase the goal of artificial intelligence 
as making machines do things that intelligent teachers do. These 
instructor attributes would include having expert knowledge of 
a subject area, the ability to gauge a student's understanding of 
that subject, and the ability to "implement strategies" for im- 
proving the student's knowledge (Burns and Capps, 1988, p. 1). 
These are the three fundamental components behind intelligent 
tutoring systems (ITS), or in the area of writing instruction, 
intelligent computer-aided composition (ICAC). While the pros- 
pect of ICAC excites almost all the interview subjects, only those 
three currently working in that area, Hugh Burns, Dan Burns, 
and James Parlett, see AI as having an impact on CAC programs 
in the near future. 

Indeed, only three ICAC programs currently exist, Confer, 
MINA, and Thoughtline, and only the last is available commer- 
cially. There are two formidable hurdles in the development of 
ICAC programs: (1) the development of natural language pro- 
cessing (i.e., allowing a computer to translate English into 
machine language); and (2) the problem of defining the knowl- 
edge domain. Natural language processing is desirable in any 
intelligent tutoring system, simply because users can commu- 
nicate with the program in a language they already know. 
Indeed, one of the earliest attempts at such an interface, William 
Woods's Lunar program, took place because NASA had assem- 
bled a mountain of data about the recently arrived Apollo II 
moon rocks, but had only a Fortran programmer who could 
access the information from the computer. NASA wanted ge- 
ologists to be able to dial up the computer and make inquiries 
of it in English. 

In his effort to create the necessary natural language capability, 
Woods developed a parsing device called an augmented transition 
network (ATN), a breakthrough in natural language processing 
(Johnson, 1987, p. 105). The ATN provided the computer with 
a mode for understanding and applying the rules of English 
grammar; in other words, the ATN gave the computer syntactic 
understanding. That breakthrough was the first important step 
in overcoming the natural language barrier. However, sentence 
parsing requires semantic processing in order to make meaning 
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of natural language; the two are inextricably intertwined. Terry 
Winograd, a leading AI researcher and critic, explains: 

People are able to interpret utterances which are not syn 
tactically well formed, and can even assign meanings to 
collections of words without use of syntax. This list "skid, 
crash, hospital" presents a certain image, even though two 
of the words are both nouns and verbs, and there are no 
explicit syntactic connections. It is therefore wrong to insist 
that some sort of complete parsing is a prerequisite to 
semantic analysis. 

On the other hand, people are able to interpret sentences 
syntactically even when they do not know the meanings of 
the individual words. . . . Much of our normal conversation 
is made up of sentences like "Then the other one did the 
same thing to it," in which the words taken individually do 
not provide clues to enable us to determine the meaning 
without a complete syntactic analysis. 

What really seems to be going on is a coordinated process 
in which a variety of syntactic and semantic information 
can be relevant, and in which the hearer takes advantage 
of whatever is more useful in understanding a given part 
of a sentence. (Qtd. in Johnson, 1987, pp. 117-118) 

Winograd's main point is that the natural language puzzle will 
only be solved when our ability to program the syntactic meaning 
of words is complemented by our ability to program what AI 
researchers call "pragmatics," the semantic meanings of lan- 
guage. 

Natural language processing has been accomplished more 
effectively in some fields; intelligent tutoring programs have 
been developed in fields such as physics, geology, and economics. 
But in those cases, the knowledge domain can be assigned strictly 
defined boundaries. For a program in the field of geology, for 
example, the language base is fairly well defined, and the 
meanings of that language base are well understood. In com- 
position, the whole world of knowledge is the domain, and thus 
the challenge for ICAC is the central challenge of natural 
language processing, the challenge of programming the rhetorical 
context. This has been most effectively performed in Parlett's 
Confer, because the program deals with a very limited knowledge 
domain — the text-based analysis of a single short story. In 
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keeping the subject and its analysis strictly defined, Parlett can 
make his knowledge domain declarative instead of qualitative, 
the latter knowledge base still being outside the reach of ICAC 
program design. Hugh Burns has outlined the hurdles for ICAC 
programs n his 1984 article "The Challenge for Computer- 
Assisted Rhetoric. ,, He calls for "intelligent systems that have 
the capability to understand concrete domains and to make 
inferences" (p. 18). His ideal system will know its uses, its user's 
writing, and all its variations, and it will know which writing 
projects are due and for whom — and it will operate with natural 
language processing. 

With somewhat less ambitious goals, Confer comes at the 
natural language problem from another angle. The program 
plays the role of expert teacher- writer and leads students through 
a dialogue about a single text, Walker Percy's essay, "The Loss 
of the Creature/' Instead of being built around an ATN or some 
other parser, it uses complex pattern matching and some lexical 
equivalents. While this approach is limited for a general natural 
language processor, it can be made successful when the knowl- 
edge domain is restricted enough for the designer to anticipate 
users 7 input. The most famous program to use pattern matching 
was Weizenbaum's ELIZA, which simulated the role of a Rogerian 
therapist, offering canned responses to recognized keywords or 
strings (Weizenbaum, 1976, pp. 36-45). Pattern matching works 
in Confer because a single essay represents a clearly defined 
domain; the program can take a student's input and, after 
breaking it into phrases, match the words in each phrase to a 
fairly extensive set of words (referred to as "tokens") in the 
expert module of the program. When a match occurs, Confer 
responds with output determined by the expert module, where 
the student is in the program, and by the pedagogical rules 
activated at the time (Parlett, 1987, p. 98). The program performs 
fairly well in terms of syntactic ability, with an average of one 
error for every 42.3 lines of system output in the tested prototype 
(p. 98). Those same tests revealed high semantic performance, 
with no reported instances of conversational failure or break- 
down (p. 114). Given such performance, Parlett argues that 
"context-sensitive pattern matching does, in fact, constitute a 
legitimate approach for developing such systems now" (p. 117). 

JO.; 
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Parlett (1987) argues thai the key to making pattern matching 
work, both in terms of syntactic/semantic performance and in 
accommodating the world knowledge associated with writing, 
is to "constrain the content area of the domain of inquiry, only 
from the system's perspective." (p. 117). The program requests 
users to make connections between the Percy essay and their 
world experience, but it does so from the perspective of the 
program. In other words, it asks users to bring their knowledge 
to bear on the essay, a domain where it does have expertise. 
One important effect of that demand is that readers are forced 
into a close reading or New Critical approach to the story, while 
other critical approaches are inoperable within the program. 
Parlett's long-term goal is to integrate Confer with an authoring 
system that would allow instructors to create Confer programs 
for any texts they desired. Such a program would ask questions 
of the instructor about a given text, building its own expert 
model for that text. An instructor could create Confer programs 
for an entire semester's reading and then use the program "as 
a stand-alone assistant to the teacher for these texts, with little 
further work required on the system for that academic term" 
(p. 24). In writing courses with narrowly defined constraints, 
such as the writing of lab reports or, perhaps, technical writing, 
a Confer authoring system might prove very useful. 

Unless such an authoring system is developed, my research 
suggests that artificial intelligence will continue to reside on the 
periphery of CAC design efforts, largely as a result of expense 
and expertise. Most AI software is written in LISP or one of its 
derivative forms. Every statement in LISP is a list or part of a 
list, usually marked off by parentheses. As a result, even simple 
LISP programs are difficult to read, even by experienced LISP 
programmers (Parlett, 1987, p. 69). Because LISP is an interpreted 
language, it is very slow to process programs. Ideally, it should 
be run on a LISP machine, a computer designed with a LISP 
environment and meant to run LISP programs, but these are 
quite expensive. The Xerox 118 Dandelion, on which Confer was 
written, and its successors cost between $25,000 and $40,000 
each, depending on the models purchased and their respective 
price schemes. Furthermore, because LISP-written programs 
demand so much memory (in its micro version, Confer requires 
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18 megabytes of hard-drive storage and 3 megabytes of RAM), 
they are not very portable into the microcomputer environment 
where most students write. 

The interview subjects working in AI are optimistic about its 
impact in the near future. However, the rest of the interview 
subjects agreed with Taylor when he said: 

I'm in a camp that says natural language processing is too 
far away to be of any use to me right now. And I think it 
may be twenty or thirty years before natural language 
processing is really developed well enough to handle just 
any old thing that you will type in ... I think it's too far 
away for me to worry about, so I don't put it in my 
programs. (Taylor, 1989b, interview) 

Even those interviewees who work in large design teams, people 
who are less worried about immediate applicability in the writing 
classroom and who have good equipment and funding resources, 
did not see AI as being an impact technology in CAC program- 
ming in the near future. 



Reward and Recognition 

Designing and developing CAC software is a time-consuming 
and difficult task; on this point, all the interviewees agreed. 
While there are no consistent, nationwide standards for the 
treatment of CAC development efforts, research suggests that a 
lack of reward and recognition is more common at the end of 
the development continuum inhabited by full-time teachers like 
Schwartz and Kaplan, than at the end inhabited by researchers 
and design team leaders like Woodruff and Smith, where reward 
and recognition are readily available. Given that research design 
teams account for only a small percentage of CAC software 
development, the implications of the research are that most CAC 
software developers suffer from a lack of institutional incentive. 

This hypothesis is certainly borne out of the results of the 
EDUCOM survey on academic software development. Indeed, 
the findir gs were rather dismal: 
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The results of the interviews indicated that incentives were 
not generally available to faculty. Release time seemed to 
be tied to the availability of funds on campuses and, for 
the most part, was available only through external funaing. 
Since criteria for promotion and tenure were established at 
the department or school level, there were few campuswide 
standards that gave credit; others counted it as a publication 
if it was published; and still others did not accept devel- 
opment activities as promotion criteria at all. Generally 
four-year institutions appreciated development only if it 
resulted in some kind of publication. The potential to 
improve the level of instruction was not a significant factor. 
(Keane & Gaither, 1988, p. 55) 

Sixty percent of the survey respondents cited a lack of release 
time as a serious impediment to software development, and 50 
percent cited the fact that development efforts did not count 
toward promotion (p. 56). Keane and Gaither assert that the 
demoralizing lack of support reported by people like Schwartz, 
Kaplan, and the survey respondents is the single moit important 
factor "in sustaining decentralized development efforts" (p. 63). 

The EDUCOM survey gathered information on institutional- 
wide programming efforts in the full range of disciplines. Many 
of the interview subjects indicated that the lack of support 
reported by EDUCOM is even worse for the CAC program 
developers because they typically work within English depart- 
ments. Some argued that they suffer marginality even within 
the field of composition. Wayne Butler humorously illustrates 
the point: "I'm an English education person in an English 
department, teaching composition on computers — I'm the lowest 
form of life on my university's food chain" (Butler, 1991, 
interview). Selfe sees CAC work as having potentially a broad 
impact on composition studies and English studies, but she 
argues that CAC efforts are largely ignored by both groups: 

I contend that our success in terms of this broader impact 
is by no means guaranteed, or even feasible, given our 
particular position within the profession of English studies. 
A full decade after the birth of computers and composition 
studies, we are, indeed, part of an exciting intellectual 
debate; we are discovering fascinating relationships among 
computers, writers, and teachers of writing. But we are not 
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having a generalized effect on our profession; we are not 
necessarily leading the thinking that goes on; we are not 
always a focus of professional debate or even curiosity. We 
are a group of scholars who attend each other's presenta- 
tions, but .who seldom hear our ideas echoed in more 
general intellectual exchanges. We exist if you will, on the 
margin of English studies. (Selfe, 1989b, p. 2) 

Selfe sees composition theory informing CAC work, but not a 
complementary reverse of that influence. She asserts, "It's not 
a permeable membrane in both ways. It's only permeable in 
one way" (Selfe, 1989a, interview). 

There are a number of forces at work in the marginality of 
CAC researchers and developers. One of the most important 
factors in that marginality is that English departments, in very 
many cases, range from being outright hostile toward CAC work, 
to simply being unsure of how to evaluate CAC efforts. Consider 
the case of Wresch, creator of Writer's Helper, one of the most 
commercially successful CAC programs on the market, and a 
leader in the field. In 1982, he was a tenure-track faculty member 
at a community college, and his work on the program was 
progressing well. He recalls: 

I had received an equipment grant from Apple, so I could 
do some of this work [programming] at home. I also had a 
contract with NCTE to write that first book, The Computer 
in Composition Instruction. Things were looking up for me 
as a developer and as comeone who was beginning to 
understand where computers might fit in. My reward from 
the English department was to be fired because, they said, 
I was dealing with computers, and I had no business doing 
that as an English teacher. (Wresch, 1992, interview) 

Wresch appealed the decision, and it was reversed, though he 
became convinced that he would not receive tenure when the 
time came because he was "messing with computers." 

Wresch left the community college for a faculty position at 
the University of Wisconsin at Stevens Point. More importantly, 
once there, he joined the computer science department, where 
he could continue to work on his software program, to work 
with teachers and computers, and to have those efforts be 
valued. In contrast to his earlier experience, Wresch went from 
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assistant professor to professor in four years, was given early 
tenure, and now chairs his department. Switching disciplinary 
camps was a drastic measure, but Wresch is not optimistic about 
changes occurring in the reward and recognition structures of 
English departments. He remembers winning the prestigious 
NCRIPTAL /EDUCOM award for Writer's Helper in 1988, and 
what he calls "one of the saddest meetings I've ever gone to" 
after the awards ceremony: 

Those of us who had won an award got together after the 
awards ceremony, and we were very very high — we had 
just picked up a check for five thousand dollars, we had 
this huge trophy ve had just stood in front of a crowd of 
3,000 people who had applauded us, and we were each 
convinced that they had applauded for us individually Then 
we got into a room and talked about development and what 
it would take, and in discussing our individual experiences, 
we discovered that what we had in common was that each 
of us had been working for nearly a decade, each of us 
had been working largely alone, none of us had been getting 
support or recognition from our institutions, and we had 
continued working despite a lot of obstacles. I don't know 
what to do about institutions. I don't see that situation 
turning around much. (Wresch, ibid) 

For Wresch, it meant finding an environment that was compatible 
with his interests, and this meant moving to computer science, 
though he remains quite active within English studies through 
his activities in professional organizations. 

Given the newness of the technology and the lack of any real 
history of technologically based research in English studies, the 
work of CAC researchers remains a difficult challenge to the 
traditional English department in terms of evaluation and reward. 
Joseph H. Bourque (1983), for example, recalled his department 
chair's surprise at his request to have one of his programs 
considered a publication. 

In his article, Bourque argues the validity of CAC work toward 
the advancement of knowledge, and he goes on to set up some 
standards for considering it as such. Bourque argues that CAC 
software requires the developer to have a thorough understand- 
ing of the field, as well as expertise in pedagogical theory, 
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cognitive research methods, and programming. He also argues 
that the act of creating a program is essentially the same as 
writing a manuscript (pp. 69-70). Bourque is not wholly accurate 
in his argument; the present study, for example, has revealed 
the ways in which some program development efforts require 
no programming knowledge on the part of the developer. 
However, Bourque's guidelines for English department evalua- 
tion of CAC development efforts are more helpful. He suggests 
that evaluation of CAC work and programs be based on: 

1. Substantive soundness. The program should be based on 
the latest and best research in the discipline [composition 
studies]. 

2. Pedagogical soundness, The program should reflect sound 
and effective classroom practice. 

3. Efficiency. Just as the length of a scholarly article is not an 
indication of its quality, a computer program is not to be 
judged by its bulk. 

4. User friendliness. The computer program should be easy to 
use, even for students and faculty who know nothing about 
computers. 

5. Documentation. No program should be dependent on the 
availability of its author for use or further development. 

6. Demonstrated use. Evidence that a program is being used 
locally, regionally, or nationally can provide further indi- 
cation of the worth of the material, (p. 73) 

Bourque's guidelines would not be inappropriate for the eval- 
uation of a textbook, and many CAC programs might be con- 
sidered in that light. Yet, other programs may help redefine our 
concept of writing, and in a sense, give birth to new pedagogy, 
new research, and new theory. If these programs are accompanied 
by significant theory, then the CAC effort has more value than 
the production of another textbook. The important point, here, 
is that these kinds of guidelines could help make clear a 
department's criteria for CAC development work. While the 
guidelines for any given department will necessarily be geared 
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toward that department and its particular institutional demands, 
the key is that those demands be articulated and that departments 
make clear the ways in which CAC efforts will come into j, iay 
in deliberations over promotion and tenure. 

Those discussions are only now beginning to occur because 
English departments are faced with continuing pressure to 
integrate computers into their writing curriculum, even when 
they would rather not. For example, an alumna of the University 
of Maine recently donated a computer writing lab to the English 
department, who accepted it only on the insistence of the 
academic dean. It is more common for English department CAC 
enthusiasts to be in a fight with other departments over scarce 
computer resources, but this example points to the kinds of 
resistance these researchers face within their own departments 
as well. The pressure to integrate computers into the writing 
curriculum has led to what McDaniel has called the "white coat 
syndrome," the hiring of one department member to act as a 
computer specialist upon whom the pressure of CAC develop- 
ment can be unloaded (Selfe, 1989a, interview). Selfe sees the 
newly hired CAC specialist as being in a position to force a 
departmental clarification of policy regarding CAC work: 

I think that when they get hired, people who are in 
computers are going to have to go to their department 
chairs. It is going to be the mutual responsibility of the two 
to clearly articulate in written form the expectations, the 
professional expectations, of the chair and of the person, 
so that they don't fall prey to changing expectations. I think 
we can do that, but we have to take a proactive role. We 
can't sit back and assume that a department head is going 
to understand what we know about computers. We have 
to educate the head, and the head has to educate us about 
educational constraints, and there has to be a negotiated 
stance that comes out of that. (Selfe, ibid) 

Until that happens, release time, promotion, and tenure will be 
more readily available for CAC developers in research settings. 

When CAC development is tied to research goals, as it is in 
the cases of WE, CSILE, Notes, and other programs developed 
in the research design team model, the reward value of those 
efforts is tied to their success in producing publishable research 
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findings. In each of those cases, the programs will not be widely 
used in writing classes for some time to come. The programs 
that emerge from the other three models are intended to improve 
the writing curriculum, but many English departments, as we 
have seen, place little value on them. If CAC developers are 
being denied departmental rewards, this may be due to English 
departments' lack of understanding about the nature of their 
work, and also because academic culture does not place much 
value in pedagogical improvement. This was the conclusion of 
the FIPSE Technology Study Group: 

The conflict faculty face when forced to choose between 
the rewards of improved learning in a course and the 
rewards of publishing research results is deeply rooted in 
the culture of higher education. We recognize that the 
traditional and most significant system of faculty reward, 
tenure and promotion based on disciplinary research, is not 
flexible enough at many institutions to encompass work in 
developing curriculum. (Balestri, 1988, p. 46) 

If CAC researchers focus wholly on the classroom use of their 
programs and neglect their work's theoretical implications and 
research value, then their work will continue to be as under- 
valued as that of any hardworking classroom writing teacher — 
no matter how effective their programs are in improving or 
facilitating student writing. 

Certainly, while CAC programs proliferate, a review of the 
literature on CAC reveals a dearth of theoretical work. Perhaps 
this is due to the newness of the tools themselves; CAC re- 
searchers have been so busy trying to understand them that 
they have not stood back long enough to explore their broader 
theoretical implications for composition. Selfe believes that "we've 
been so busy playing that we haven't had time to look back at 
the field and make those intellectual bridges that are going to 
increase commerce between the two areas" (Selfe, 1989a, inter- 
view). Wresch agrees and sees publication tied to software 
development as one possible inroad into institutional reward 
structures: "If article publication is the currency of the realm, 
that's one way to continue your software work" (Wresch, 1992, 
interview). CAC development efforts will have to be bolstered 
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with a stronger theoretical orientation, with more published 
research, if CAC developers are to partake in the departmental 
reward structure and "legitimize" their efforts within traditional 
institutional value systems. 

Selfe also believes that the marginal position assigned to CAC 
development work has more to do with deeply rooted ideological 
orientations than with academe's stress on research over teaching 
or over humanists' lack of technological understanding. She 
believes that the rhetoric of technology in the writing classroom 
reveals a "reformist vision of computer-supported classrooms": 

one in which students are active, engaged, central, and one 
in which technology is helping teachers address racism, 
sexism, inequitable access to education, and other disturbing 
political-social problems now operative in our educational 
system. (Selfe, 1989b, p. 5) 

She sees the rhetoric of CAC as being closely akin to the rhetoric 
of feminism, each of them being a "highly politicized, rhetorical, 
persuasive discourse that calls for change and that commits a 
community of scholars to positive reform" (p. 6). 

Drawing on the work of Suzanne Clark, Selfe identifies a 
fundamental and ideological opposition between CAC research 
and the values of the discipline: 

Such discourse does not go over well at the academic center 
of our profession, say, at the latest MLA convention, where 
logocentric, unsentimental, agonistic values still often hold 
sway, where our colleagues think that scholarship should 
be objective, apolitical, and arhetorical. (p. 7) 

Clearly, there is CAC work that does not fit the reformist vision 
Selfe articulates — the network programs that "monitor" writers 
at work or Smith's WE come to mind. However, the collaboration 
that comes in a program like Interchange, the empowerment of 
marginalized students which networks and telecommunications 
can allow, the challenge to notions of authorship in a hypertext 
environment, and the idea of shared databases like the one in 
CSILE all serve to challenge the traditional value structure of 
academic discourse. Even the way these programs are devel- 
oped — collaboratively — rejects the traditional value of sole au- 



11 J 



Forces That Impact CAC Software Design 



95 



thorship of intellectual property. And when their work is reported 
on in print, CAC developers speak in terms of fundamental 
changes to our present understanding of textuality and its 
management, a discussion generally "couched in terms of hope 
and change" (Selfe, 1989b, p. 5). 

Ted Nelson ascribes the marginality of CAC developers to an 
even more fundamental disagreement over intellectual orienta- 
tion than the one identified by Selfe. In his book Literary Machines 
(1987), he uses, as his starting position, CP. Snow's notion of 
two diametrically opposed intellectual cultures: the culture of 
technology and the culture of the humanities. In Nelson's view, 
English departments lack an understanding of computer tech- 
nology as discussed by Bourque, and the values of associations 
like the MLA which Sdfe alludes to are only symptomatic of 
this larger, cultural split. While Nelson's book is quirky and 
sometimes overstates his position., his characterization of the 
battle between the "technoids" and the "fluffies" has the ring 
of truth: 

About the only thing the groups have in common is their 
shared view of computers [that they are technical] ... But 
one interesting aspect of the two cultures is their view of 
each other in the world. Each sees the other group as "those 
people in their little corner, unaware cf the big wide world." 
To the Fluffies, this real world is history art, literature, and 
the little corner is "technical things." To the Technoids the 
real world is that of technical questions and ideas, and the 
little corner is the artsy-craftsy nook of bygone concerns. 
(Sec. 1, p. 13) 

Nelson goes on to argue that the computer, through networking, 
worldwide databases, and hypertext in particular (Nelson is one 
of the key developers of hypertext), stands to radically change 
our understanding of text and that humanists, as managers of 
text, and technoids, as those who possess the tools to work with 
the technology, will have to reconcile in order to guide these 
dramatic changes. 

Nelson is calling for intellectuals who can combine the tech- 
nological and humanistic perspectives, researchers he refers to 
as "systems humanists": 
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As far as I am concerned, both the Technoids and Fluffies 
are in their own little corners. In the broaden view, the goals 
are the long ones of civilization — education, understanding, 
the preservation of human values — but we must use today's 
technologies. I call this view "systems humanism." Civili- 
zation as we know it is based in part on running water. 
That system had to be thought out. Similarly, somebody's 
gotta design waterworks for the mind. But it should be 
someone who understands the fluidity of thought. (Sec.l, 
p. 14) 

While CAC work is not mentioned specifically by Nelson, CAC 
developer? come very close to fitting the role he describes. 

English departments must come to recognize the special role 
their CAC faculty —acting as "technology critics; , to use Selfe's 
term — play in the reconciliation of technology and the human- 
ities (Selfe, 1992). Such recognition and accompanying support 
for CAC work would go far in ending the often -decried lack of 
good CAC software. For even as the EDUCOM survey reported 
the dismal treatment of CAC development efforts, the survey 
team concluded that software development continues and that 
the future of such efforts is promising if the issues of reward 
and recognition are addressed successfully (Keane & Gaither, 
1988, pp. 63-64). 



Funding 

Developing CAC programs is an expensive proposition. As 
was illustrated in the earlier discussion, costs are tied to the 
model of development in use. The lone programming model is 
obviously much less costly than the big-budget research design 
effort. The EDUCOM Software Development Survey does pro- 
vide some sense of general software development costs. For 
example, the University of Akron estimates the development 
costs of a one-hour computer instructional module to be about 
$10,000. To develop one hour of intelligent tutoring software, 
the California State University at San Francisco estimated about 
1,000 hours of development time, at about $50 per hour (Keane 
& Gaither, 1988, p. 58). 
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Sources of funding can range from the bank account of an 
individual developer, as in the case of the prototype for Prewrite; 
to the institutional funding of the sort Kaplan received for the 
development of Prose; to large grant-giving entities like the 
National Science Foundation (NSF), the Fund for Improvement 
in Post-Secondary Education (FIPSE), or the Office of Naval 
Research (ONR), the latter having funded software development 
efforts at Carnegie Mellon University. Corporate funding, es- 
pecially from industry giants like IBM and Apple, can also be 
an important source of project monies. Commercial sale of CAC 
software does not yet sustain substantial development efforts, 
though as the market for such software grows and more effective 
forms of marketing and distribution are discovered, the for- 
profit sale of software may become a more viable source of 
development funds. In cases such as Wresch's Writer's Helper, 
which is being used in 3,000 high schools and colleges, sales 
have provided ample reward for the developer's efforts, yet this 
kind of success in marketing CAC programs is still quite rare. 

Generally speaking, the lone programmer, small design group, 
and entrepreneurial approaches to program development are 
either under- or only adequately funded. Research-based design 
teams enjoy the most generous funding, especially through ties 
with corporations (which, of course, have a vested interest in 
their efforts) and with the defense industry. Perhaps because of 
competition in the former, and the inherent secretiveness of the 
latter, interview subjects working in the research design model 
were reticent about discussing their sources of funding. None 
would divulge their project budgets, although c mith, as men- 
tioned earlier, used a figure of $450,000 to discuss the manage- 
ment of funds in such projects. Woodruff would only identify 
the number of funding sources for CS/LE, seven, and say that 
they were a combination of corporate and educational sources 
(Woodruff, 1989, interview). Neuwirth identified FIPSE as a 
funding source for one project, but she would not discuss funding 
sources further, other than to say they were typically a combi- 
nation of government and private foundations (Neuwirth, 1989a, 
interview). 

A relative abundance of funding allows research design teams 
to sustain complex, ambitious projects. However, funding of this 
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magnitude carries with it some considerable burdens. As Smith 
made clear, spending at this level requires tighter controls and 
more accountability, adding a greater number of bureaucratic 
duties to the task of project manager 0-B. Smith, 1989, interview). 
Projects that cany this type of funding seem to require a more 
highly controlled development protocol; for example, Neuwirth 
cites her role as principal investigator on grants as a reason for 
closely monitoring her programmers (Neuwirth, 1989a, inter- 
view). Finally, at least with the corporate sponsors, there can be 
pressures to bring a product to market before the developers 
are ready. Woodruff explains: 

As you know, programs of this size are very expensive, and 
ihere are very few private agencies that can afford them. 
So sooner or later, you have to go to the corporate sector. 
And as much as they would like to assume a philanthropic 
attitude, they want to see something that will sell their 
equipment ... as soon as possible. Yesterday wasn't soon 
enough for them. You've just got to work out that balance. 
You've got to convince everybody involved that the research 
is necessary, and that if you push it out before the research 
is completed, you'll probably have a product that is detri- 
mental to the goal you are trying to achieve. (Woodruff, 
1989, interview; emphasis his) 

Despite the pressures they may exert, large funding entities like 
corporations and government agencies will continue to be the 
primary monetary sources for the expensive efforts of the re- 
search design teams. As a result, continued pressure will be 
brought to bear on research-based programs to serve both market 
and government needs. Moreover, because most of the major 
funding entities are interested in advanced research and devel- 
opment, CAC developers with solely pedagogical aims will 
continue to see very little of that money coming th-rir way. 



Software Publication 



If faculty overcome the challenges of developing software 
and actually produce good and useful programs, they still have 
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a crucial decision to make regarding the dissemination of that 
software. When programs were more modest in scope, the market 
less broad, and the costs of development lower, faculty-devel- 
oped programs were often shared for free or for the cost of the 
diskette on which they were stored. Oftentimes, programs were 
simply made available on campus networks. As recently as 1988, 
an EDUCOM survey revealed that "the majority of academic 
software developed for the curriculum was not published by 
any of the major book or software publishers" (Keane & Gaither, 
1988, p. 51). This state of affairs resulted in poor dissemination 
of software and little monetary incentive for faculty to continue 
their development efforts. 

However, as the market for CAC software has grown, faculty 
developers are increasingly turning to textbook or software 
publishers. Unfortunately, textbook publishers have not served 
the interests of faculty software developers very well, despite 
their extensive sales networks. Based on the experience of those 
interviewed, academic software publishers are doing a much 
better job of handling faculty-based software, though there are 
signs that textbook publishers may be growing more sensitive 
to the demands of effective software marketing. The publishing 
histories of Kaplan, Martin, and Davis's Prose, Helen Schwartz's 
SEEN and Organize, and Wresch's Writer's helper generally 
illustrate the strengths and weaknesses of dealing with textbook 
and software publishers. Making a program suitable for the 
widest number of users, keeping up with evolving technology, 
conducting effective marketing, making royalties and finding 
capital for ongoing software development, and keeping software 
theoretically and pedagogically sound are all tied to the choices 
developers make regarding the dissemination of their software. 
Programs have lived and died on the basis of those choices, so 
the evolution of software publishing is of substantial importance 
in the discussion of faculty-based software development. 

Kaplan's experience with McGraw-Hill illustrates the worst 
possible consequences of disseminating software through a major 
textbook publisher. In 1988, unhappy with Kinko's Academic 
Software Exchange's marketing of Prose, Kaplan and her col- 
leagues scld the program rights to McGraw-Hill. She is blunt 
in her assessment of that decision: "Anybody working on 



118 



100 



Writing Teachers Writing Software 



software should not publish it vdth a book publisher!" (Kaplan, 
1991b, interview). McGraw-Hill has failed to upgrade Prose, in 
essence making the program almost obsolete in the Macintosh 
environment. That was never Kaplan's expectation, but the 
contract she and her colleagues signed with McGraw-Hill allows 
the publisher to decide when redevelopment of the program 
should take place. Kaplan explains the problem: 

The environment in which Prose has to exist has changed 
many times since we finished programming the version sold 
to McGraw-Hill. But in our contract we were unable to 
negotiate what I consider to be satisfactory decision points 
about when redevelopment would begin. And since the 
cc ir~^ay does not understand software, and wanted always 
to think of it in terms of the cycles by which they produce 
textbooks, this was not very successful. (Kaplan, ibid) 

Helen Schwartz had the same experience with Wadsworth's 
handling of her program Organize: "One of the reasons I signed 
with them was that I thought they'd keep the software current, 
which they never did" (H. Schwartz, 1992, interview). Further 
exacerbating Kaplan and her colleagues' situation was the fact 
that the original McGraw-Hill version of Prose still had bugs in 
it. The three developers corrected those problems, but McGraw- 
Hill had already packaged and shrink-wrapped the flawed 
version of the program and did not want to repackage the 
manuals with the new bug-free version of Prose. 

Prose was originally designed for the Apple Macintosh, but 
McGraw-Hill planned to target the large DOS market by con- 
tracting with a programming firm for a DOS rewrite of the 
program. Kaplan, Martin, and Davis were often consulted during 
the project, and though they had no direct decision-making 
power, they strenuously objected to a number of design decisions 
that the hired programmers were making. Kaplan recalls: 

They adapted a text editor that had no word-wrap capability. 
Their first thought was, "Well, this will be acceptable. English 
teachers don't have very high expectations." They said that 
they had already built some things around this editor and 
that changing it would be expensive and compli- 
cated. . . They made some programming decisions that were 
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very bad, and after McGraw-Hill had thrown a certain 
amount of money into the problem and came up with 
nothing close to acceptable, they just cut the funding — so, 
no more money. (Kaplan, ibid) 

As a result, Prose never made it into the DOS environment, 
losing a potential market and costing Kaplan and her co- 
developers potential royalties of some magnitude. Indeed, sales 
of Prose have been light, and McGraw-Hill scarcely markets the 
program at all. 

A different kind of decision on the part of Wadsworth, on 
the question of copy protection, led to a similar loss of sales for 
Organize, and thus royalties for Schwartz. Piracy, the unauthor- 
ized copying and distributing of a software program, continues 
tc be a difficult issue in disseminating software. While copy 
protection schemes can be incorporated into a program, they 
often complicate the program's use, affect its reliability, and 
make it more expensive (H. Schwartz, 1990, p. 26). Wadsworth 
decided to copy-protect Organize, a decision to which Schwartz 
did not object. Unfortunately the right-protection scheme Wads- 
worth employed proved complicated for users. Schwartz says: 

The way they right-protected meant that people had to do 
a fairly complex operation at the beginning, even to get the 
program to work. So, essentially, it never sold. They started 
giving it away. (H. Schwartz, 1992, interview) 

Because the program was now being given away free, it paid 
no royalties. Schwartz at least enjoyed an advance on the 
program. No longer feeling invested enough in the project to 
pressure for its redesign, as well as feeling frustrated with 
Wadsworth, she allowed the issue to rest. 

William Wresch has had a markedly different experience with 
Writer's Helper, which is marketed through CONDUIT, an aca- 
demic software publisher. CONDUIT, in existence since 1972, 
began as a National Science Foundation-funded consortium of 
universities developing and sharing faculty-developed software 
on a not-for-profit basis. Now based at the University of Iowa, 
CONDUIT operates much like any small publishing house, 
though its not-for-profit status frees it from some of the con- 
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straints of profit-making publishers. Wresch rejected large text- 
book publishers (coincidentally, McGraw-Hill was one those he 
rejected) to market his Writer's Helper with CONDUIT. He says: 

I really made a correct decision m dealing with McGraw- 
Hill. The more I talked to them, the more I realized they 
didn't know anything about software, and that if I were to 
publish through them, I was not only going to publish, but 
I was going to spend my life training them to understand 
what software was. So I went with a software publisher 
because I needed that level of help. (Wresch, 1992, inter- 
view) 

Even as early as 1983, when Wresch decided to contract with 
CONDUIT, the consortium had ten years of experience in 
marketing academic software to colleges and universities. 

The experience that CONDUIT had in creating and dissemi- 
nating software to the college market led to a much more active 
partnership between Wresch and the organization than in Ka- 
plan's experience with McGraw-Hill. Wresch explains: 

They could give me a great deal of help on what my 
interface should be. They knew what necessary documen- 
tation should be. They had a clear sense of how to turn a 
product that worked in my classroom into something easy 
enough to use so that people in other classrooms could use 
it. (Wresch, ibid) 

That consultation extended beyond mere advice to CONDUIT'S 
actually rewriting some of the program code. For example, in 
order to make the program run faster, they added, by Wresch's 
estimate, a full 10 percent to the program's original code: 

I found this astounding. They didn't say, "Here are some 
things you need to rewrite." They just went ahead and 
rewrote it themselves — and I'm really grateful for that. 
(Wresch, ibid) 

The program was released in 1985 and went on to sell approx - 
imately 1,000 copies over the next three years. 

User feedback, Wresch's sense of developments in the field 
of composition, and new technological developments all led to 
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a substantial revision of the program, with CONDUIT once 
again doing the programming. The result was the release of 
Writer's Helper Stage 77, in 1988. Wresch doubled the number of 
activities from twenty-two to forty-four, updated the interface 
to include easy-to-use pull-down menus, and made the program 
modifiable by teachers. A recent extension of this version in- 
cluded six more activities and works within the MicroSoft 
Winuows environment. While CONDUIT has always had in- 
house programmers, their wholesale rewriting of Writer's Helper 
code was a first for them. Molly Hepler, product manager for 
English and foreign languages at CONDUIT, cites a dual purpose 
in CONDUIT'S willingness to rewrite the program. On the one 
hand, she says CONDUIT recognized that faculty developers 
had little time to undertake such work: 



We try to relieve the professor of trying to stay up technically 
with changes in the field and with new developments. 
Working in C or C+, making programs network compati- 
ble .. . it gets complicated, and it's unfair to expect faculty 
to keep up with that. (Hepler, 1992, interview) 

On the other hand, CONDUIT enjoyed great success with Writer's 
Helper and saw it as the centerpiece of their software catalogue. 
Rewriting the program in C (Wresch originally used BASIC), 
which allowed for the new interface and increased functionality, 
was good for Wresch and for CONDUIT. 

CONDUIT'S sense of the program's potential was borne out 
with the release of Writer's Helper Stage 77. With a renewed 
marketing effort by CONDUIT, ->ales of the program doubled, 
and it is now being used in about 3,000 high schools, colleges, 
and universities. CONDUIT, lacking the extensive in-the-field 
sales staff common to textbook publishers, uses a combination 
of direct mail, advertising in professional media, and convention 
booths to market Writer's Helper Their sales to date have been 
quite good for a CAC software program. Because field sales are 
geared toward direct student sales, possessing an ir.-the-field 
sales force is of little help in marketing software. Hepler explains 
that there continues to be no viable market base for direct sales 
of software to students: 
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Lots of publishers tried to market software. They thought 
they could package it with a textbook and sell directly to 
students through college bookstores. It didn't happen. Text- 
books are expensive, and adding even $10 to the cost means 
students aren't going to buy. And, at least for now, insti- 
tutions are the ones buying the software, not students. 
Maybe if that right combination of textbook and software 
package occurs it will generate sales; then we might be at 
a disadvantage without a sales network— but that hasn't 
happened yet. (Hepler, ibid) 

Moreover, the sales people who represent textbook companies 
are often ill-prepared to discuss software when a faculty person 
does show some interest. As most writing teachers know, text- 
book sales often begin with a knock on the door by the area 
representative. Usually working out of home offices and trained 
to deal with print texts, these sales people often have no training 
in or familiarity with the software program they carry. Indeed, 
an informal survey of twelve regional sales representatives who 
carry some form of CAC software revealed that eight had never 
used their programs, and four had merely seen their programs 
in "getting acquainted" demonstrations at regional or national 
company meetings. None could discuss the programs in detail 
or address anything but the most basic technical questions. 
Textbook publishers have simply not kept pace with the tech- 
nology, and that filters down to a large, but finally inept, 
marketing force who tries to sell a product for which the parent 
company has shown no commitment. 

Commitment to their software offerings was the quality Wresch 
and Schwartz saw most apparent in CONDUIT'S handling of 
their programs. Schwartz praises CONDUIT'S handling of SEEN 
and the collaborative nature of the organization's relationship 
with her. At the time she entered into an agreement with 
CONDUIT, she and the editors there had proposed revisions for 
the program. As they did in Wresch's case, CONDUIT took 
responsibility for substantial rewriting of the program code. 
These changes included an authoring system that allowed cus- 
tomized tutorials, on-line examples, an updated interface, and 
network capability. They also wrote the program manuals. 
Schwartz, like Wresch, is convinced that CONDUIT greatly 
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improved the program, made it more marketable, and made the 
program more flexible for the teachers who would use it in their 
classrooms. She also readily admits that aspects of the program, 
for example, the networking capability, would never have been 
included without CONDUIT'S willingness to take on the pro- 
gramming work: "I knew that what I could do alone was not 
as good as what they could do." She adds, "I have nothing but 
praise for CONDUIT. They are academics, but they also know 
marketing, and they're very good. I never have to worry about 
quality control. They understand software" (H. Schwartz, 1992, 
interview). At least for the time being, software publishers like 
CONDUIT seem to be highly preferable to textbook publishers 
for faculty who are seeking a way to disseminate their software. 
Certair ^ Wresch is as adamant as Kaplan in his advice to avoid 
textbook publishers: 'Tn every case where a bookseller has 
bought software, the software developer has lived to regret it" 
(Wresch, 1992, interview). 

Will that continue to be the case? There are encouraging signs 
that textbook publishers, who are showing a revived interest in 
software, are growing more sensitive to the demands of handling 
and marketing. The first such sign is the creation of software 
editor positions within the companies. Kim Richardson, software 
developer at HarperCollins, is charged with acquiring software 
products, working with developers, and developing a catalog of 
programs that include more stand-alone software not tied to 
handbooks or texts. She says: 

The history of textbook publishers and software has not 
been good, in large part, because publishers had no history 
of working with software. They tried to set that work within 
a book model, and it just didn't work. Textbook acquisition 
editors were signing up programs they didn't know, that 
were not developed properly, and that were then not 
marketed properly. (Richardson, 1992, interview) 

In contrast, Richardson's sole focus is software, so she has 
nurtured her connections with CAC researchers and developers. 
For example, one of her first projects at HarperCollins was 53rd 
Street Writer, a word processor and on-line handbook developed 
by the Daedalus Group. 
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Richardson sees textbook publishers coming to value software 
more than they did in the past: 

The attitude is changing week to week, for the better. In 
the past six months I've seen a growing awareness of 
software. Oh, there are people who would rather not 
acknowledge my existence within the company but there 
are editors who are really interested and want to know how 
software can help their lists. (Richardson, ibid) 

While editors' increased interest may still be tied to improving 
their text sales, it is important to note that Richardson was hired 
with the specific long-range goal of building a catalog of free- 
standing software. 

One challenge facing Richardson is the longstanding practice 
of bundling free software with texts as a marketing strategy 
While she admits that many editors see this as a way of selling 
more texts, faculty, accustomed to getting free software with 
their texts and often expecting it, are another hurdle. They will 
have to be convinced that software is a viable component of 
their curriculum and worth their students' dollars. She explains: 

We often bundle free software with texts and many faculty 
have come to expect it is a catch-22 that isn't good for any 
of us. It would be better if students purchased software. 
That would generate sales for us, royalties for developers, 
and the increased development that would support would 
provide higher-quality software for instructors and students. 
(Richardson, ibid) 

Richardson's argument echoes The FIPSE Technology Study 
Group's conclusion that distribution of free software, through 
many channels, has failed to adequately support ongoing soft- 
ware development (Balestri, 1988, p. 82). With 53rd Street Writer, 
Richardson makes the program available as a $9.95 free-standing 
program or as a $4.96 ancillary to a handbook. It is still too 
early to tell if the recently released program will enjoy good 
sales in either format. 

Richardson acknowledges that field sales staff are often un- 
prepared to discuss software products with potential customers. 
They are emblematic of their industry, slowly coming to grips 
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with a technology that does not fit easily within their print-text 
frame of reference (and in that, they might be said to resemble 
many in English studies). Moreover, texts are still the mainstay 
of their sales, and will remain so for some time to come. As 
Richardson points out: 

Whenever we have a national meeting, we set up a room 
with computers and all our software products and invite 
our saLs staff to come in and use the programs and get 
better acquainted with them. But there are so many dis- 
tractions at these meetings, and the sales people have so 
many books they need to know, that they just don't get in 
there enough to work with the software. (Richardson, ibid) 

On another level, technology can be a problem. Richardson 
explains that HarperCollins sales people use Compaq laptops 
and DOS machines, but that when they are given Macintosh 
programs, they are unable to use them and learn the product. 
She partly compensates for these shortcomings by attending 
computer and writing conferences, engaging in the same "net- 
working" that her colleagues in the software publishing houses, 
people like CONDUIT'S Hepler, use to make sales contacts. In 
addition, she offers to make sales presentations with the 
HarperCollins sales staff. 

HarperCollins does not have on staff the in-house program- 
mers which CONDUIT can devote to a software project, but 
Richardson outlines a relationship between faculty developers 
and the publisher that may avoid some of the pitfalls that beset 
a program like Prose. If Richardson is presented with a program 
that she finds interesting, she can negotiate with the developer 
to continue the development and to present the program for a 
review process similar to the one used for texts. If the publisher 
accepts the finished product, the developer can negotiate a one- 
time license fee or a royalty contract, with 15 percent royalties 
being the rule-of-thumb average for software products for both 
textbook and software publishing houses. This arrangement 
offers little improvement over past arrangements, but another 
possibility is for the publisher to offer an option agreement that 
pays the developer an advance and gives HarperCollins the first- 
right-to-buy. That advance can be used to pay for development 
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costs, and it has ranged from as little as $500 to several thousand 
dollars for programs in which Richardson had great interest. In 
either case, Richardson has developed a pool of outside pro- 
grammers and developers who work with faculty developers. 
She acknowledges the importance of program revision, but points 
out that the decision to undertake the expense and trouble is 
driven by the market demand for the product. In any event, 
she uses a standard three-year term for software contracts, and 
she argues that a developer unhappy with the pace or timing 
of program revision could end the relationship with Harper- 
Collins and enter into a new relationship with another publisher. 

After their initial interest in and failure with software, followed 
by their subsequent loss of interest, textbook publishers are once 
again showing renewed interest in CAC software. As Richardson 
says, "Computers are here to stay, and we know that now" And 
the proliferation of computer writing labs means that the huge 
composition market needs software products. This time, however, 
the involvement of software editors like Kim Richardson, the 
apparent commitment of their superiors to marketing software 
and developing a catalog of free-standing programs, and the 
growing interest of textbook editors in software programs suggest 
that entering into an arrangement with a textbook publisher 
does not necessarily have to be the disaster it once was for 
many faculty software developers. 



The Future of CAC Development Models 

Anyone who works with computer technology makes predic- 
tions about the future with hesitance and some anxiety. The 
technology is moving ahead at dizzying speed, and because that 
progress is fueled within a highly competitive corporate market, 
research and development efforts are highly secretive. Yet, my 
research suggests that this is a critical period for CAC software 
development, a time when a number of forces have come 
together to discourage many computer and writing people from 
creating software programs, even as new technologies have 
made the actual development easier than bef^e t For the im- 
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mediate future, there is likely to be a movement up the design 
continuum away from the efforts of the lone developer model 
However, there are, on the horizon, developments which may 
help mitigate that trend, but probably not for another four to 
five years, according to the individuals interviewed for this study 
Considering the forces at work in the area of CAC software 
design (e.g., changes in technology, the reward and recognition 
structures of institutions, funding questions), I would like to 
suggest the probable direction of the four approaches to devel- 
opment that I identified earlier. 

The Lone Developer 

As things now stand, the lone developer approach for CAC 
development is underfunded, goes unrewarded, and is facing 
increased technological complexity. While many of the best CAC 
programs now available have been produced by classroom 
teachers trying their hand at software development, this ap- 
proach has become increasingly difficult to sustain; almost none 
of these developers has gone on to create a second program. 
There are likely to be fewer programs emerging from this model 
for the time being. Those programs that do emerge will be 
necessarily limited in scope and goals, even as CAC programming 
seems to be moving in the direction of programs such as WE 
and CSILE, which operate as comprehensive writing environ- 
ments that encompass the whole of the writing process. 

There is disagreement on the place of such "small" programs 
in a market accustomed to using large, multifunctional software 
programs such as Word, WordPerfect Writer's Helper, and presum- 
ably, at some point, a writing environment program such as WE. 
Kaplan believes software programs that address only one small 
part of the writing process will seem unworthy of the time and 
effort their faculty designers invested in them, especially in light 
of software that is already available and the expectations of 
users: "It's very difficult to adopt something that maybe addresses 
a tenth of what [users] need to do" (Kaplan, 1991b, interview). 
On the other hand, if writing environment programs are designed 
to allow the integration of smaller programs, the latter may find 
a viable place in the design world. This is the position of 
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Woodruff, who admires chese "little programs/' as he calls them 
(Woodruff, 1989, interview). He sees them as "targeted to do 
one thing and to do it very well/' and he believes that "if they 
do that very well, there'll always be a place for them. I think 
the total environment will have to allow movement in and out 
of those programs" (Woodruff, ibid). Since fully integrated 
writing environment programs like WE and CSILE largely exist 
in research contexts, it will be some time before this question is 
answered. Hypertext authoring programs, however, are quite 
another matter. 

As I have argued elsewhere (LeBlanc, 1992), authoring pro- 
grams, particularly hypermedia authoring programs, have the 
power to revive faculty-based software development in both the 
lone developer and small design group approaches. Apple Com- 
puters introduced HyperCard for the Macintosh five years ago, 
and CAC developers are starting to explore more fully its 
implications for design. For example, Chris Anson (1989), of the 
University of Minnesota, is currently working on a hypertext 
version of rhetorical cases, what he is calling "deep cases," 
complex and descriptively rich scenarios that use banks of 
accessible information. The DiPardos' (1989) program, described 
earlier, is creating new kinds of text that aren't possible in 
traditional print media. John McDaid (1989; 1991) has his 
freshman writers producing hypermedia essays. Hypertext and 
hypermedia (as it becomes more affordable) can allow developers 
to create complex programs right now 

As faculty see and use hypertext /hypermedia applications, 
and as those authoring programs become even easier to use, 
there should be an increase in faculty-based software develop- 
ment. Ron Fortune, who is creating hypertext applications that 
combine manuscript studies and writing, reports just such a 
phenomenon: 

So often I hear faculty colleagues talking about what they 
would like to do in their courses, and it makes no difference 
whether it's a literature course or a writing course; your 
first reaction is that the ideal tool for doing this is hypertext. 
After I gave a presentation on what I was doing with 
hypertext, faculty came up to me and said, "I would like 
to try this. Can we get together sometime and talk about 
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it?" I read that as a very positive sign — that the interest is 
there. (Fortune, 1991, interview) 

At my own institution, where we have installed a hypermedia 
classroom and faculty courseware development facility, an in- 
vitation for proposals went out to fill ten available spots for 
faculty software developers. With no release time or additional 
support offered, ten faculty from various disciplines, with almost 
no programming experience, eagerly signed on, with a second 
group waiting in the wings. To borrow Catherine Smith's (1991) 
comment, ''They seem minds stunned with possibility" (p. 237). 

The lack of any real DOS-based hypertext systems has so far 
slowed the amount of software development being done by 
faculty, given the huge installed base of DOS-based computers 
in higher education. As noted earlier, lone faculty developers 
work with the hardware available to them, and for a vast 
number of faculty, that is the IBM or one of its compatibles. 
Apple's competitors have rushed to enter the hypertext market, 
but as Tim Bajarin, vice president of Creative Strategies Research 
International, says, "In the Mac arena [the HyperCard idea] is 
understood. In the PC arena, I don't think anybody has any 
idea of what it is" (Flynn, 1989, p. 21). That was so for some 
time, but in 1991, IBM introduced its first integrated hypermedia 
system and this year began shipping its Ultimedia system, the 
first DOS system to run hypertext applications at a speed 
comparable to Apple's Macintosh computer. If ToolBook, the 
Asymetrix-produced, hypermedia authoring program packaged 
with IBM systems, can do for the DOS environment what 
HyperCard is doing for the Macintosh environment, the power 
to effectively create software will be in the hands of thousands 
of technology-sawy faculty. Helen Schwartz's Discourse Detective 
and Ron Fortune's manuscript work have both been created 
using ToolBook and hopefully signal the first wave of DOS-based 
hypertext applications to join the superb work that other CAC 
specialists like Moulthrop, Joyce, McDaid, and others are doing 
in the Macintosh environment. 

Helen Schwartz envisions a middle ground in which faculty 
purchase software programs that have built-in authoring systems 
and that can be greatly and easily modified. In this case, teachers 
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are not building programs from scratch, but can take the existing 
"frame" of a program, flesh it out, and modify it in ways that 
are most useful to them. She explains: 

I think the metaphor for the coming decade is going to be 
"sampling." What we're going to do is learn to build on 
other people's work more successfully. (H. Schwartz, 1992, 
interview) 

Her point is that the reusability and transferability of blocks of 
object-oriented program code, and the authoring programs they 
make possible, will allow the easy modification of existing 
software. For example, in Schwartz's own program, SEEN, teach- 
ers can use the built-in authoring utilities to create entirely new 
tutorials within the program. Given the constraints imposed 
upon writing teachers, the lack of support or institutional reward, 
for example, Schwartz does not anticipate the widespread de- 
velopment of software by writing instructors. However, she 
believes that modifiable software programs will encourage writ- 
ing teachers to shape software in ways most meaningful to their 
students, and that giving software users that power will en- 
courage continued diversity in approaches with CAC software. 

The Small Design Group 

What is good for the lone program designer is generally good 
for the small design group, as well. Therefore, advances such 
as OOP, hypertext, and authoring programs, when they become 
more readily available, will offer the same benefits in this 
approach as they do for the lone faculty designer. Indeed, the 
small design group is likely to take advantage of those benefits 
even sooner. Given their collaborative structure, small-group 
design teams are able to assemble a broader range of expertise 
by bringing in diverse specialists. By employing an audiovisual 
specialist in their design group, for example, they could more 
easily expand into hypermedia than the writing teacher who 
has not worked with videodiscs or animators. Because OOP 
design allows for the independent construction of objects (or 
independent blocks of code), members of the small-group design 
team can delegate responsibility for portions of the program 
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more easily than they can with traditional programming lan- 
guages, thus speeding up their development time. Yet, like the 
lone programmer, they are likely to continue to suffer from 
underfunding and lack of rewards. 

While the small design groups often work with the hardware 
they find readily available, the fact that their funding is often 
partially supplied through grants allows them a little more 
flexibility in equipment choices than the lone developer typically 
enjoys. For example, Kaplan and her collaborators were able to 
choose the Macintosh as their architectural base for the devel- 
opment of Prose, This flexibility in hardware purchasing will 
allow small design groups to take advantage of technological 
developments more rapidly than sole program designers. 

There is likely to be more pressure on small design group 
members to publish research based on their program efforts and 
use. While that same pressure may be felt by many lone 
programmers, because small-group developers are more likely 
to have grant funding, their development efforts are more 
formalized, often justified in terms of research goals, and more 
publicly central in their scholarship. In contrast, while some 
lone programmers may also seek to work that way and have 
their programs treated as research related, most, like Mimi 
Schwartz, have treated software as an ancillary piece of course 
material — that is, a small piece of a much larger pedagogical 
approach, developed on one's own time away from professional 
duties, and often produced without complementary research 
efforts. Kaplan, on the other hand, sees Prose as one of her 
primary scholarly accomplishments and posited it as her "book" 
in her successful tenure application at the University of Texas 
at Dallas. Simply put, published research is still the "currency 
of the realm," as Wresch puts it, and will be necessary if CAC 
developers wish their work to be the basis for promotion, tenure, 
or even release time. While this added burden may slow down 
program development, the need for research results may have 
the positive effect of forcing more user testing and evaluation 
than is typical in this model. While the results of this testing 
should provide valuable research data for program developers 
who need to publish, it should also result in better program 
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efforts if these developers are afforded the funds to revise their 
programs. 

The growing number of microcomputers in the writing class- 
room is creating a growing and viable market for the sale of 
CAC software, a fact reinforced by the knowledge that college 
microcomputers are overwhelmingly used for the task of writing. 
A review of the 1990-91 software logbook at the Springfield 
College microcomputer lab revealed that almost 80 percent of 
the software signed out was for word processing. As the FIPSE 
Technology Study Group points out, one source of development 
funds may lie in more effectively tapping this market through 
better distribution and marketing of CAC software (Balestri, 
1988, p. 82). This may seem commonsensical, but CAC devel- 
opers' longstanding habit of making their software available for 
free or for a very nominal fee resulted in a subsequent lack of 
profit and provided no funds for future development. In a 
commercial arrangement, "Receipts from the sale of software 
pay the developers, the graphic artists, and the publisher's 
expenses in marketing and supporting the product; most im- 
portantly, receipts can pay for the development of a new 
generation of software" (Balestri, ibid). While the gift-giving 
approach of "public domain" software is endorsed by the FIPSE 
Group (Balestri, ibid), the expense of program development, the 
general lack of funds, and the amount of time and effort 
demanded by program development make such generosity much 
rarer. 

The success of Wresch and Schwartz in working with CON- 
DUIT suggests that the small group may often be comprised of 
faculty and publishing professionals. Though Wresch and 
Schwartz both worked as sole programmers through the early 
development and even initial distribution of their programs, 
when they joined CONDUIT, the development of their programs 
became a small-group effort — a highly successful, collaborative 
one. The effective small-group approach of the future may 
consist of one or more faculty members together with the editor, 
programmer, and marketing expert of the publishing company. 
One benefit of such collaboration would come in having the 
marketing expertise, sense of user needs, and technological 
expertise of the publishers included in the early development 
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stages, thus precluding the often substantial program revisions 
that occur when software passes from the hands of faculty 
developers into those of the publishers. 

The Entrepreneurial Design Group 

If these groups can more effectively market their programs, 
the expanding market for CAC software has the potential to 
sustain their design efforts, as well as to fund their expanded 
development goals and their purchase of the technology nec- 
essary to meet those goals. Because they self -market their 
products, professional developers like Dan Burns cannot rely on 
word-of-mouth referrals and vendor displays at conferences for 
the sale of their software. Burns has tried direct-mail marketing 
for academe with disappointing results: 

When we send direct mail to businesses we get about 2.2 
percent in sales. To colleges and universities, it's been about 
1 percent at best, which is just not enough to sustain the 
costs of this marketing approach. (Bums, 1989, interview) 

As a result, Burns has been forced to tap the academic market- 
place through conferences such as the Conference on College 
Composition and Communication and the Computers and Writ- 
ing Conference, and has had to subsequently lower his expec- 
tations for college sales. For the program, less money means less 
revision, and Burns has had to delay his plans for an academic- 
based version of Thoughtline. 

The entrepreneurial design group, comprised of academics 
who start their own software company as a separate ana 
secondary pursuit, can more effectively operate with conference 
and word-of-mouth marketing. They can do so because their 
software efforts are not their primary source of income, and 
because their contacts within academe make word-of-mouth 
referrals a much more effective marketing device than it is for 
an outsider like Burns. However, they cannot be blase about 
sales. For example, the Daedalus Group members, recognizing 
the amount of time and effort they were devoting to the company, 
were forced to double the price of their software in 1990 in 
order to cover their costs. At that, Butler admits that the group's 
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contract programming work kept it afloat until sales of the 
Daedalus Instructional System could finally sustain operations. 
Profits, if they are abundant, can cover costs and allow such 
design groups to purchase new hardware and software tools, 
allowing them to keep up with changes in operating environ- 
ments and the marketplace in ways which textbook publishers 
find it harder to do. If profits are scarce, these design groups 
will find it more difficult to take advantage of technologies that 
could greatly influence the programs they design — hypermedia, 
for example. 

While their careers as academics insulate entrepreneurial de- 
sign group members from the vicissitudes of the marketplace, 
they nonetheless are forced to juggle their software development 
and the academic pursuits necessary for their professional suc- 
cess. For example, Paul Taylor, recently hired at Texas Tech, 
admits that his work for the Daedalus Group greatly slowed his 
academic progress. Taylor also asserts that his work with tech- 
nology was not viewed positively by some search committees 
during his job search: "It scared off most of those I spoke with" 
(Taylor, 1989b, interview). Wayne Butler, who is now on the job 
market, echoes that sense and has downplayed his technology 
work in some cases. Once they are hired, the entrepreneurial 
designers will r rost likely find it difficult to balance their full- 
time academic responsibilities with their software development. 
Fred Kemp agrees: 

I think it's a very tough thing to do. I think to design 
software with the kind of originality and risk taking that 
characterized my early days ... I believe that with the 
responsibilities I have and the demand upon me to publish 
texts, that I don't have the time to take those risks, to play — 
I mean play in a very serious way, to learn the new 
programming languages, for example. (Kemp, 1991, inter- 
view) 

If they wish to succeed as academics, that is, to receive promotion 
and tenure, and to create CAC software, members of the 
entrepreneurial design group, like members of the small design 
group, will have to demand clarification from their chairs on 
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the treatment of CAC work in decisions about tenure and 
promotion, and they will have to produce publishable research. 

It may be necessary for entrepreneurial designers to follow 
the Daedalus Group strategy of keeping company work and 
academic work publicly separate. For example, if Daedalus Group 
members are presenting a paper at a conference, they perform 
no Daedalus work there, that is, no working in the booth or 
meeting with interested customers. Butler points out that in 
some disciplines, a connection between academic life and the 
outside corporate/governmental world is prized, engineering or 
business, for example: 

The business school would much rather have the CEO of 
a corporation as a lecturer in the department, because that 
person knows about business, has been out there doing it. 
I think, in the humanities, there's a skepticism about those 
who would make money from their knowledge, or some- 
thing like that. (Butler, 1991, interview) 

While none of those interviewed expressed a desire to sever 
their ties to academe, the precedent for such a break exists in 
other fields, where strong corporate markets exist for academic 
expertise in program design. It will be interesting, in the next 
few years, to see if any entrepreneurial design group members 
become full-fledged, professional software developers like Dan 
Burns. Butler does not dismiss that as a possibility for some 
members of the Daedalus Group, though it has not happened 
yet. 

The Research-Based Design Team 

Design teams operating in research universities will continue 
to thrive and may come to represent a larger percentage of CAC 
development efforts. The research-based design team has played 
an increasingly important role for a number of reasons. First, 
being situated in a research university, design teams are in a 
position to integrate new technologies as those technologies 
emerge. This is true, in part, because these technologies are 
often developed in such settings, because the expertise necessary 
to effect their integration is more likely to be available at research 
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institutions, and because those institutions are more likely to 
have the funds necessary to purchase new technologies. In 
addition, because their goal is research rather than the dissem- 
ination of software, they are under less pressure to see their 
product in the marketplace. 

As illustrated in the earlier examination of this model members 
of the research design teams operate in an environment where 
their efforts are valued and rewarded. This kind of professional 
atmosphere will not only continue to nurture design efforts, but 
it may draw CAC developers who are currently working in other 
models. Parlett sees this as a distinct possibility: 

I think the whole movement in design efforts is toward 
cognmve-based research groups like Chris Neuwirth's or 
John Smith's. They have the money they have the resources, 
and they are doing good stuff. Who could blame someone 
like a Paul Taylor for choosing to work in that environment? 
(Parlett, 1989, interview) 

If Parlett's prediction is correct, then research design teams will 
not only have the best technological resources available to them, 
but they may have many of the best CAC developers as well. 

Perhaps the most important development in this model is the 
continued movement toward complex and comprehensive writ- 
ing environments like WE and CSILE. The development of a 
single, cohesive writing environment represents a significant 
break from previous macro-environments or "macroprograms" 
like Writer's Helper, which offers a diverse menu of subprogram 
offerings. Macroprograms like Writer's Helper or HBJ Writer allow 
their users to pick and choose among subprograms for those 
that best meet their needs as writers. They can choose "strategies 
that accord both with individual writing styles and with the 
demands of both their topics and their intended audience" 
(Rodrigues & Rodrigues, 1984, p. 85). The pluralism of macro- 
programs is largely rejected in the new "environment" programs. 
Parlett explains the rationale: 

This design philosophy [of macroprograms] is characterized 
by an "objective" or naive pluralism wherein all instructional 
methods and strategies for invention or prewriting are 
treated as potentially and equally legitimate, without regard 
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for the pedagogical stance enacted by the teacher in the 
classroom. Such a pluralistic tolerance removes the burden 
of strategy evaluation from the teacher and places it solely 
on the students, themselves, who must sample such a mixed 
bag o* approaches in its entirety before adopting one or 
more strategies for the work at hand. (Parlett, 1987, p. 58) 

A strong advocate of Parlett's view, John Smith argues for 
comprehensive writing environments designed around a highly 
structured cognitive model of the writing process: 

While these programs [CAC software] offer writers new 
tools, they do so piecemeal and with minimum concern for 
the large-scale structure of the writing task. Their designs 
often seem driven more by what the computer can be easily 
programmed to do rather than by what will help writers 
most. Badly needed are tools designed from the outset to 
closely match and to augment the inherent cognitive pro- 
cesses that human beings use to perform the complex, 
multifaceted task of writing. (Smith & Lansman, 1987, p. 
1) 

Woodruff's willingness to integrate independently developed 
"little programs" in CSILE, a total writing environment, is not 
shared by Smith, who urges a stricter adherence to a highly 
formalized design model (Smith, Weiss, & Ferguson, 1987). 

Wresch sees some important design issues in the emergence 
of writing environments like WE and believes that such programs 
are out of synch with the needs of teachers and the demands 
of writing classes: 

Every teacher I've talked to resists that approach for a very 
simple reason: you only get students for fifty minutes. What 
they wanted, and still want, and request from me are 
activities that can be done in a fairly short period of time. 
The environment that you create is not the software; it's 
the classroom. The teacher comes in and says, "Today we're 
going to do module A or module B," as part of a larger 
process that they, the teachers, have ei visioned as taking 
place over a week, or two weeks, or three. So the glue that 
holds everything together is not the software — the software 
never takes over anything — it's the classroom. The class has 
to be able to get into a particular activity, to do something 
the teacher thinks is of value, and to get out again before 
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that bell rings or the period comes to an end. (Wresch, 
1992, interview) 

Wresch argues that software designers need to keep the teacher 
central in the design concept, and that software must not only 
give teachers control over the programs but also empower them 
to decide what is important for their classrooms. As writing 
environment programs move from the research setting to the 
marketplace, teachers, the key consumers in the CAC market, 
will largely determine the ability of writing environments to find 
acceptance in the classroom. It will be interesting to see if 
Wresch' s sense of their needs is borne out. 

An Overall View 

While diversity still exists in approaches to CAC software 
development, recent years have seen an increase in the number 
of one-time developers who abandon further projects as well as 
a general drop-off in programming efforts. One key reason for 
the decline in CAC software work has been the growing com- 
plexity of technology and the corresponding increase in program 
sophistication. The arrival of authoring tools and hypertext, as 
well as the decreasing costs of technology, may reinvigorate 
faculty-based programming on the part of classroom teachers. 
However, formidable obstacles still exist for those interested 
faculty and include the marginalized position of CAC specialists, 
a lack of institutional reward and recognition, and difficulty in 
acquiring funding. While overcoming technological hurdles is 
significant, our success in addressing institutional issues will be 
the key in assigning CAC software development its proper value 
and in keeping it within the province of English studies. 

For now, th* increased cost of CAC development and the 
growing complexity of programs are moving CAC development 
up the continuum toward the research design model. That model 
will account for a greater number of CAC programs, though the 
lag period between their development and their common use in 
writing classes will remain significant until memory, processing 
speed, and larger screen sizes become much more affordable. 
The value placed on CAC program development in university 
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research programs will make it the most welcoming environment 
for CAC specialists. 

The work of CAC developers in the other three models will 
not be properly rewarded by English departments in the near 
future, due in part to a lack of appreciation for the intellectual 
rigors of good CAC work, to some deeply rooted anxieties about 
technical culture, and to an ideology that devalues work that 
emerges from the classroom and is meant to improve the 
curriculum. The research model has developed in an environment 
where these obstacles are much less pronounced or are entirely 
absent. Many of the developers working in the lone programmer, 
small-group, and entrepreneurial group models have been people 
with no real stake in departmental reward systems. They might 
be said to have been marginalized in the departmental structure 
during their program development efforts, being either graduate 
students (Taylor, Kemp, Carter, Parlett) or working as adjunct 
faculty (Mimi Schwartz, Kaplan). In the latter case, faculty 
developers have generally produced only one program, finding 
the lack of reward and the effort required for program devel- 
opment to preclude new development projects or even revisions 
of their original programs. In the former case, CAC work has 
slowed progress in the graduate program and will pose interesting 
problems for these developers as they enter the profession or 
decide to pursue another career. The first generation of com- 
position specialists with CAC as their doctoral focus are only 
now entering the field. In many cases, they are likely to be 
burdened as their department's "computer specialist, ,, falling 
victim to the "white coat" syndrome; they will be expected to 
publish and teach full loads; and they may find very little time 
for their CAC program work. 

Take, for example, the case of Fred Kemp. Kemp was hired 
by Texas Technological University as an assistant professor. He 
is director of developmental writing, director of the writing 
program, the English department coordinator for the Texas 
Assessment of Skills Proficiency (TASP), and overseer of their 
expansion of computer-based writing facilities. In addition to 
that, he is trying to maintain his responsibilities to the Daedalus 
Group. His colleagues worry. Parlett says: 
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It's real hard trying to fulfill academic duties, particularly 
the way they pile them onto new faculty, especially writing 
faculty. And then try to do any computer programming? I 
don't know how Fred does it. It's not the supportive 
atmosphere I work in at the Human Resources Lab. (Parlett, 
1989, interview) 

The little time left for program development might drive CAC 
specialists to research settings that nurture this kind of work. 
The situation may spark an increase in professional development 
groups, if the marketing strategies can make that endeavor 
viable, or it may simply cut down on the number and quality 
of new CAC programs, forcing some developers to abandon 
their efforts entirely. 

The nonresearch-based design models stand to be reinvigo- 
rated by new technologies, hypertext most immediately, but also 
object-oriented programming and authoring programs. The im- 
pact of hypertext is being felt across the whole design continuum 
and only awaits better DOS-based programs to prompt a whole 
new generation of software, particularly from the small design 
and entrepreneurial design groups. However, the complexity of 
hypertext systems and OOP will dissuade all but the most 
dedicated lone programmers. $r 

In trying to determine the direction of CAC program devel- 
opment, my research suggests that the work of research-based 
design teams will play a much more prominent role in the field 
overall. They have the funds, the technology, and the resources 
to develop complex programs in an atmosphere that values and 
rewards their efforts. The success of the entrepreneurial design 
model will be tied to its success in tapping the growing CAC 
market. The size of that market is suggested by looking at just 
one of its parts. Consider the figures: 

1. The number of computers used in elementary and second- 
ary schools quadrupled from about 250,000 to 1983 to 
over one million in 1985. 

2. Three-quarters of the schools which had not previously 
used computers began to do so. 
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3. During the 1984-85 school year, approximately 15 million 
students and 500,000 teachers used computers as part of 
their schools 7 instructional programs. (Qtd. in Herrmann, 
1989, p. Ill) 

For those academics working in the entrepreneurial model, their 
CAC work is likely to be constrained by professional duties and 
pressures. That will also be the case for members of the small 
design group. In both instances, a change in attitudes by English 
departments will go a long way to reinvigorating these models. 
If the success of the research-based model confirms the old 
adage about the rich getting richer, the lone programmer's fate 
seems to confirm the second half of the saying. A lack of reward, 
a lack of funding, and the growing complexity of the technology 
and design goals are making the lone programming effort a 
thing of lore, a relic of the days of BASIC and 64k machines. 
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CAC Software Design 
and the New Literacy 

While computer and writing specialists may still feel margin- 
alized within the profession, their fundamental belief that tech- 
nology is radically redefining writing and most other literary 
practices is taking hold. A growing chorus is proclaiming the 
digital revolution, as Richard Lanham (1989) terms it. A call to 
order is being issued within English studies, either directly, as 
in Andrea Lunsford's 1991 MLA address, or implicitly through 
the increased attention paid by mainstream journals such as 
NCTE's College English and MLAs Profession; the growing num- 
ber of CAC sessions at the MLA and CCCC annual conventions; 
or the now steady stream of professional texts from publishers 
such as NCTE, Boynton/Cook, MLA, Ablex, and others. There 
was little choice in the matter. 

The limitations of print text have become all too nakedly 
apparent in the light shed by the computer monitor. For example, 
the transmission speed of electronic text, the ability to move 
through a hypertextual database and easily reassemble data, and 
the compact mass storage possible with electronic text are ideally 
suited to library science, information services, and business. 
While the return on their investment has been questioned 
(Moran, 1991, p. 2), American corporations are spending huge 
sums on electronic communications systems and are adopting 
technologies such as electronic mail, hypermedia, and computer 
conferencing at a furious pace. Like it or not, corporate needs 
and practices exert a powerful influence on curricula in both 
secondary and higher education, and corporate America's wide- 
spread adoption of the computer as a communications tool will 
have a significant impact on the English classroom. As Lanham 
(1989) says: 
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Some of the billions of dollars American business and 
government spend to train their employees are being spent 
in redefining the "textbook 7 ' — and, almost in passing, the 
codex book itself — into an interactive multimedia delivery 
system. Sooner or later, such electronic "texts" will redefine 
the writing, reading, and professing of literature as well, 
(p. 265) 

While the profession struggles to understand the changes in 
its subject area and to rewrite its curriculum, on-line documen- 
tation and hypermedia systems have altered technical writing 
irrevocably and have created the first direct link between the 
changes in corporate communication and undergraduate edu- 
cation (Shirk, 1991; Zimmerman, 1989; Carlson, 1988; Bernstein, 
1988). As Muriel Zimmerman (1989) said to her colleagues in 
technical writing: 

Many of us will acquire programming skills and write or 
edit on-line menus and messages. Some of us will become 
hypertext information architects. Some of us will have 
facilitating roles in a technology whose outlines we can 
only guess at. . . . We may continue to be called writers; 
modern truckdrivers are teamsters, and firemen ride diesel 
trains — but I don't think that we will do much of what 
Thelma Thistleblossom [a Timp Software grammar- and 
style-checking program] can do, or even much of what we 
presently do. (p. 245) 

Zimmerman's use of the future tense should not mislead anyone. 
These changes are taking place now, and they serve notice on 
those of us working in composition that our students must be 
prepared to function in a world of electronic discourse when 
they leave our classrooms. 

The new literacy has not been thrust willy-nilly upon English 
studies because of the demands of the workplace; as technology 
has moved beyond word processing and stand-alone computers, 
compelling connections have emerged between electronic com- 
munication and many of the current theories informing both 
literary and composition studies. As George Landow and Paul 
Delaney (1991) assert, the 

deep theoretical implications of hypertext converge with 
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some major points of contemporary literary theory and 
semiological theory, particularly with Derrida's emphasis on 
decentering, with Barthe's conception of the readerly versus 
writerly text, with post-modern's rejection of sequential 
narratives and unitary perspective, and with the issue of 
"intertextuality" In fact, hypertext creates an almost em- 
barrassingly literal embodiment of such concepts, (p. 6) 

This notion of electronic text's ability to operationalize theory, 
which print text resists, is echoed in a number of recent works. 
P*vid Bolter (1991) claims, "Not only reader-response and 
spatial-form but even the most radical theorists (Barthes, de 
Man, Derrida, and their American followers) speak a language 
that is strikingly appropriate to electronic writing'' (p. 161). 
Stuart Moulthrop (1991) sees hypertext uniting deconstruction 
and the production of all text, everything from the freshman 
essay to the novel. 

Similarly, computer and writing specialists have been quick 
to point out the compatibility of computer-based writing and 
much of the current thinking in composition theory and pedag- 
ogy. In composition studies, Trent Batson (1988) echoes Landow 
and Delaney's (1991) assertion, claiming that "it was as if some 
of the current theories about how to write were developed 
specifically with networks in mind, even though the developers 
didn't know it" (p. 32). Early CAC research was enthusiastic 
but often unconnected to theory and larger issues of literacy. In 
1989, calling for more theoretical work in computers and writing 
and the changing nature of literacy, Cynthia Selfe (1989c) wrote: 

Our profession will have to work diligently in the next few 
years to identify and explore the changing nature of literacy 
with a computer-supported writing environment, and to 
consider the implications of these changes for our teaching, 
(pp. 13-14) 

CAC research has begun to take that broader view and has 
explored more thoroughly the connections between on-line 
literacy behaviors and theory. For example, in more recent work, 
Thomas Barker and Fred Kemp (1990) describe the new "post- 
modern pedagogy for the writing classroom" (p. 1); Janet Sldred 
(1989) has clearly outlined the way computer-based writing 
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supports sodal constructivist theory (pp. 209-216); Ron Fortune 
(1991, interview) is linking notions of intertextuality and revision 
in his hypertext-based manuscript work; and Selfe (1990) has 
explored the potentially liberatory effects of computer-based 
writing for otherwise marginalized students. The proliferation 
of computer-based writing labs, the installation of campuswide 
networks, the increasin&number of students who now own their 
own computers, and the enthusiasm of colleagues who teach in 
electronic environments have all fueled the growing interest in 
CAC within composition studies. 

At present the challenge for CAC specialists is less to convince 
their colleagues that a transformation in literacy is taking place 
and more to urge them to assume a central role in defining how 
technology and literacy will intersect. As John McDaid (1991) 
puts it: 

It seems we are in the midst of a "phase change" between 
technologies, when the characteristics of the defining me- 
dium become momentarily apparent, , , . Here is an oppor- 
tunity and, for composition theorists, a responsibility, (pp, 
217-218) 

Henrietta Shirk (1991) echoes McDaid's call to order, and she 
voices one of the key points of this book when she says, "If 
those concerned about communication do not participate in the 
development of new theories for the new technologies available 
in the field, others will accomplish this task for them 7 ' (pp, 198- 
199). The argument needs to be extended, for even Shirk relegates 
composition to a reactive position when we are in this unique, 
yet perhaps short-lived, even ignored, period that allows us to 
shape the technology through software development and thus 
become proactive in the shaping of the new literacy. We confront, 
then, a question of vision, or more precisely, a question of whose 
vision we will be working with in our classrooms. 



Relying on Corporate Creativity 

Writing teachers could wait for the computer industry's hard- 
ware and software manufacturers to create products in response 
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to their needs, but such a stance ignores the longstanding 
relationship between technological development and consumer 
need, a relationship in which technology drives need (some 
would even say dictates), not the reverse. Nancy Kaplan (1991a) 
treats this subject with great insight, reminding us that complex 
technologies arise within existing and self-perpetuating ideolo- 
gies that have the capital and power to shape those technologies 
(pp. 21-24). She echoes Richard Ohmann's (1985) assertion that 
"computers are an evolving technology, like any other, shaped 
within particular social relations and responsive to the needs of 
those with the power to direct that evolution" (p. 680). The key 
to shaping consumer need is to make the original technology 
seem "natural" to its users, so that all subsequent needs and 
consumer feedback begin with the base technology and its 
underlying assumption of "what can be," to borrow from Goran 
Therborn. If consumers of technology begin to define their needs 
in terms of the base technology, with its sets of capabilities and 
limitations, their sense of what could be is constrained from the 
outset. 

Consider just one of the technologies that has inspired so 
much interest and enthusiasm in CAC: networking. Networking 
has made possible Barker and Kemp's post-structuralist writing 
classroom. It seems to make possible new pedagogies based on 
social constructivist theories of writing, in which collaboration, 
empowerment, student-centeredness, and social-based learning 
can be realized. Yet network technology was first designed for 
military and then business use, and its design favors security, 
hierarchical relationships among users, and surveillance. At best, 
writing teachers must work to overcome those obstacles; gaining 
full freedom from them might even mean building a new network 
technology from scratch, as occurred with CSILE. In another 
example, Ron Fortune, working with ToolBook to create hyper- 
media applications in the DOS environment, complains that the 
software belies IBM's business orientation and has required him 
"to work around" those limitations (Fortune, 1991, interview). 
Because we do not create hardware (though Ontario's devel- 
opment of the ICON computer was a valiant attempt), computer 
and writing teachers will always be subject to at least that 
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amount of ideologically influenced technology in their on-line 
environments. 

Indeed, it the microcomputer were designed in response to 
writers' needs, it would most likely look and operate quite 
differently than it does now. Screen size, which affects reading 
effectiveness and thus revision, as Haas (1989) has shown, 
would have allowed long ago more than an average of fifty- 
one lines of text on a screen. Kaplan comments: 

Where did the architecture of the IBM system — which still, 
by the way, dominates the world as far as I can see — where 
did that come from? Well, it certainly didn't come out of 
anybody's notion of how people actually work with text, 
yet that actually turns out to be the single most important 
application of microcomputers. My favorite example of this 
is the notion that documents scroll down. Where did that 
come from and why is it so deeply embedded in the 
architecture of all word processing? How did it get to be 
that way? Well, it almost doesn't matter how it got to be 
that way; that it is that way really shapes our relationship 
to emerging text. (Kaplan, 1989, Interview) 

Selfe shares that view, points out the computer's military- 
industrial lineage, and suggests that the computer embodies 
elements of that background: 

What are the command lines that come up on the computer? 
They've been somewhat disguised in the later years: "Abort, 
kill, zap, and execute." Every command line comes right 
out of the military background of the computer. My suspicion 
is that it's reflected in many other subtle ways. (Selfe, 1989a, 
interview) 

As writing teachers who are exploring electronic literacy and 
struggling to answer the question "What can be ?" we might 
find that the range of answers available to us is already con- 
strained by what has been offered and what v/e accept as our 
starting point. 

In the worst case, those underlying design values result in 
networked systems like Robotel's MicroSelect video network 
system. Marketed at educational conferences, the system allows 
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teachers to monitor their students' screens, unbeknown to the 
students, and to interrupt and take over a student terminal. 
Note the pedagogical values implicit in the following excerpts 
from their marketing materials: 

No More Inattentive Students. 

The teacher can end the class' work at any point by 
preempting their screens . . . 

Better teacher control over student work. 

Computers tended to interfere with age-old, proven pedagogical 
techniques. ("MicroSelect: The Essential Tool") This particular 
product seems the computer embodiment of Bentham's Pan- 
opticon, against which Selfe (1989b) warns. As> she explains, 
the Panopticon was Bentham's design for a circular prison with 
a guard station in the middle, constructed in such a fashion as 
to allow guards to observe prisoners unobserved by the latter, 
creating a king of paranoid self-discipline in the prison population 
(p. 10). As Selfe says: 

We have not acknowledged or explored the fact, for example, 
that these electronic spaces [networks] can be used as 
"disciplinary" technologies, through which teachers control 
students and their discourse in the most traditional sense. 
(P- 10) 

Technologies like MicroSelect's network system, merely an ex- 
tension of the underlying technology's design and ideological 
basis, undermine the promise of electronic literacy. A reality of 
computers and writing, and one not likely to change, is that the 
tools the computer industry affords us are ideologically laden, 
as Kaplan, Ohmann, Olson, and others would argue, and that 
ideology may often conflict with teacher ideals and goals. 



Forging Alliances 

While collaboration between academics and corporate interests 
is common and often valued by some disciplines, for example, 
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business, engineering, and some medical fields, those relation- 
ships are fairly new to the humanities (though manning the 
conference booth of one's textbook publisher carries some of 
the same reverberations). Within the humanities such relation- 
ships have been forged most directly and visibly in computers 
and writing studies. For those working in research settings or in 
some software development programs, these alliances are as 
necessary as they are in any field that relies on what is often 
expensive technology and equipment. For example, the Computer 
Research Lab at the University of Texas was founded on an IBM 
equipment grant, and without it, the Daedalus Group would 
not have come into existence or created its software. Similarly, 
Apple Computers has given substantial support to the CSILE 
project, and the computer William Wresch used at home to first 
create Writer's Helper (then called Essay Writer) was provided 
with an Apple grant. Such funding has made some of the best 
CAC software possible, but it is, of course, in the hardware 
manufacturers' best interest to support software that moves their 
product line. 

Collaboration with corporate interests seems to inspire a 
complicated mix of reactions within the CAC community. Because 
that collaboration can mean financial support, knowledge of and 
early access to new technologies, and endorsement of one's 
work, there is a measure of pride and prestige for the faculty 
person; CAC faculty have been featured in "resource" materials 
produced by both Apple and IBM, and both companies have 
featured faculty-developed software, the latter producing poten- 
tial sales of the software and royalties for the developer Other 
perks might include travel to corporate-sponsored conferences, 
consulting opportunities, and employment possibilities. How- 
ever, many within the humanities look askance at such part- 
nerships and see them as exploitive relationships in which 
academics sacrifice their scholarly objectivity. For now, given the 
lack of institutional support and funding for CAC software 
development, corporation between developers and corporate 
interests seem a r r^ssary, if complicated, arrangement. 

Wresch, who has forged those corporate ties as visibly as 
anyone, asserts that such relationships are good for the com- 
panies, with their need for the guidance of academics, and are 
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good for the academics, with their need for support and tech- 
nological know-how. He agrees that a hardware manufacturer 
like IBM is looking for software that "it can sell and runs on its 
machines. . . that enhances its product/' but that computer com- 
panies also have a sincere and well-intentioned interest in 
education: 

They want to market to us, and they need to understand 
[the academic marketplace], but some of it is altruistic, as 
well. They are interested in who their next generation of 
employees will be, what kind of a school experience their 
own children will have. They're interested in education for 
more than simply making money, and that's true for all of 
the hardware companies I've spent some time with. They 
honestly do listen. (Wresch, 1992, interview) 

Wresch also points out that companies like IBM and Apple have 
hired many academics who go on to play key roles in shaping 
academic technology for the manufacturers: 

If you say you work with IBM, or you say you work with 
Apple, generally who you're working with is somebody 
who used to teach at a university and is now employed 
over there, so you're essentially talking with one of your 
colleagues. . . . Because they come from our milieu, they're 
not hard to talk to. They know exactly what's going on 
over there [academe], because they were, in many cases, 
over here for a decade or two before they went over to the 
company These individuals come out of an academic tra- 
dition, they are hired at some point by the hardware 
companies, and they understand our needs. (Wresch, ibid) 

Wresch focuses on the individuals who represent the corpora- 
tions, people with children, academic backgrounds, and perhaps 
similar values, and anyone meeting someone like IBM's Doug 
Short, a former medievalist, or Apple's Rich B. (last name kept 
confidential at his request), who works on educational technology 
for children, is struck by their thoughtfulness, intelligence, and 
idealistic vision for computer-based learning. That said, Apple 
and IBM are still large capitalistic entities that exist to generate 
profits, and the intersection of that ontological fact and our 
educational purpose bears further consideration and ongoing 
diligence. 



CAC Software Design and the New Literacy 



133 



Military Funding 

While corporate affiliations are not entirely new to English 
studies — many faculty have contracts with textbook publishers 
and do consulting work — military funding is another matter. 
Given the military's longstanding investment in computer tech- 
nology, it comes as no surprise that the military invests in 
software development. For example, the Army Research Institute 
has sponsored John Smith's work with WE, the Office of Naval 
Research funded the construction of Carnegie Mellon's software 
development center, and the Air Force and NASA have begun 
a joint hypertext project. Within CAC software development, 
Department of Defense (DOD) funding, which can be quite 
substantial, has occurred only within the research design ap- 
proach, yet some of those interviewed think such funding should 
be avoided. 

Reservations about DOD funding have been raised on many 
campuses and within many disciplines, but the issue had not 
arisen within composition or English studies until the advent of 
CAC software development efforts. Interview subjects were more 
guarded in their comments about DOD funding than they were 
about any other subject — in part, I believe, because the CAC 
community is still quite small and therefore has less room to 
accommodate the kind of ethical and moral recriminations often 
engendered in this debate. One interviewee, under promise of 
anonymity, said: 

It's not that the software someone produces with military 
funding is itself good or bad, it is just that on one level, 
such developers are buying into some larger enterprise in 
which the military sees their software playing some func- 
tional role, and on another level, there is ethical complicity 
in that larger enterprise as well. There are no neutral 
technologies. 

Chris Neuwirth acknowledges the ethical reservations held by 
some of her colleagues at Carnegie Mellon toward DOD funding, 
but she applies a more practical principle to the question as she 
pursues project funding: 



Richard Young put it this way to me, when I was first 



134 



Writing Teachers Writing Software 



starting. He said, "Chris, don't ever go out and get money 
where you wouldn't do what you're doing anyway" That's 
the bottom line we use to judge whether we are going to 
go after it [funding]. If it's something we would do anyway 
and the [funding] constraints aren't shoving us in a particular 
direction, then it's okay I can say that this has been the 
case for our funding. (Neuwirth, 1989a, interview) 

Unlike the affiliations with corporations, which take place across 
the development continuum, partnerships that rely on defense 
funding will likely remain within the research setting, where 
they are less controversial and more actively sought; this is not, 
however, to dismiss the issue, for if broad-based faculty devel- 
opment of CAC software continues to decline, the research 
setting stands to play a more influential role in articulating our 
vision of computer-based writing. 

The Ascendancy of Cognitive Theory 
in CAC Design 

As writing becomes increasingly an electronic practice, the 
dominance of any one approach to computer-based writing in 
the CAC software market has important implications for all of 
composition studies. Kaplan (1991a) illustrates the power of 
software to shape our thinking about information and knowledge 
making in her discussion of electronic databases: 

The database's underlying structure, usually invisible to the 
user, shapes both the forms inquiry can take, and for what 
purposes. Anyone first encountering an electronic cataloging 
system bumps up hard against such reality as he or she 
struggles to transform strategies appropriate for a system 
of card files into new mental habits for a system dependent 
on Boolean techniques. And the nature of those habits 
depends on the software's data structure and on the user 
interface constructed by the software's designers, (p. 15) 

While Kaplan does not mention it as an example, consider the 
influence exerted by Lotus 1-2-3 on the business world. It has 
now become almost mandatory in undergraduate business pro- 
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grams to teach Lotus 1-2-3, the most popular spreadsheet and 
database program in existence. Because training in Lotus 2-2-3 
or one of its imitations is almost universal, the program has 
largely come to define the way a whole generation of business 
people understand spreadsheet and database management. If 
composition studies does not find ways to support faculty-based 
software development, to encourage and reward faculty for 
learning and using new hypertextual and OOP -based authoring 
systems, and to nurture diversity in software design, then the 
only approach to CAC software development may be that of 
the research-based design team. 

Certainly, the trends examined in the previous chapter suggest 
that programs in the research-based design team model will 
account for a larger percentage of CAC programs in the future, 
either directly or indirectly, and that those programs will be 
more technically powerful than many of those originating in 
the other design models. The movement in the research-based 
design model toward writing environment programs, which 
operationalize a cognitive theory of writing, also tends to leave 
little room for accommodation of smaller programs that are 
likely to be technically and theoretically incompatible. The 
prospect of CAC software development being dominated by 
cognitive-based research teams is not a healthy or encouraging 
one, not because those groups aren't doing some wonderful and 
valuable work, but because there is great value in carrying over 
the theoretical diversity that characterizes composition studies 
into CAC software development. Otherwise, a single, dominant 
approach to software will allow technology to shape writing 
instruction as it takes place in computer environments. Instead, 
writing teachers should be able to choose from the widest variety 
of software tools possible and to shape their own virtual writing 
spaces. 

Diversity in Composition Studies 

Since Richard Young (1978) and Maxine Hairston (1982; 1985) 
argued for the existence of a "paradigm shift" in writing theory, 
it has become commonplace to refer to the movement from 
"current-traditional" (Young, 1978, p. 30) to "process" ap- 
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proaches to composition. Such a shift, they argue, is accompanied 
by and even sparked by the ''development of new theories 
which are able to provide more adequate solutions'' to the crisis 
that undermines established paradigms (Young, 1978, p. 35). 
That these theories are often competing, contradictory and 
include a wide range of research methodologies and aims has 
been generally accepted as part of a paradigmatic transformation 
in which the new paradigm struggles to define itself through 
testing and debate, establishing its boundaries and frontiers 
through theory and research. In that defining process, the various 
theories somehow coalesce over time, with some becoming more 
central for their explanatory power while others fall by the 
wayside. Until that process is complete, the argument goes, a 
diversity of approaches should be nurtured. Even adherents to 
a particular theoretical approach, cognitivists such as Bereiter 
and Scardamalia (1983), for example, argue for this pluralism 
in the field: 

On the one hand, we are impatient, as surely many others 
are, with the miscellaneous character of so much writing 
research, with its orientation toward topics or methods rather 
than toward goals, and with its generallack of cumulative 
force. On the other hand, we think that in this era of 
competing methodologies there is a special need to promote 
tolerance and a free spirit of inquiry. Writing research is 
new, and there is not much of it. It is not easy, and there 
are, as yet, no magic keys to an understanding of it. Writing 
research needs to be varied without being unfocused, guided 
by theory without being dogmatic, progressive without being 
mindlessly trendy, (p. 3) 

Implicit in this passage is the value of diversity in theory as 
well as in research. It should be noted that some see this diversity 
is undermining the attempt of composition to establish itself as 
a discipline. Stephen North (1987) writes, "It might not be too 
much to claim, in fact, that for all the rhetoric about unity in 
pursuit of one or another goal, composition as a knowledge- 
making society is gradually pulling itself apart" (p. 364). A far 
more common view, at least for now, is Stephen Witte's (1983) 
belief that various approaches to composition studies, using a 



CAC Software Design and the New Literacy 



137 



range of methodologies, come together as a "cumulative" body 
of knowledge in the field. 

Composition's accommodation of theoretical diversity has 
been paralleled in CAC software development, as a review of 
existing programs reveals. For example, Prewrite and FREE reflect 
expressivist pedagogies; Interchange and Thoughtline support 
social-epistemic theory; and WE, Notes, and Comments are cog- 
nitive-based programs. Indeed, as Janet Eldred (1989) has pointed 
out, the marketing of the microcomputer and CAC software has 
thus far paralleled movements in composition studies. First there 
were "current-traditional" programs that checked spelling and 
mechanics, programs like Grammatik, to be used on personal 
computers. At that time, the programs developed for these 
private machines were expressivist, but then both the hardware 
and the software gave way to more social concerns, manifested 
in networking, telecommunications, and bulletin boards, as seen 
in programs such as SEEN and Interchange (p. 202). 

While no single theoretical approach to composition dominates 
the software market, the subjects interviewed for this study 
suggested that the increasingly important role played by the 
research design teams in CAC software production will indeed 
favor cognitive theories of writing over other competing theories. 
Parlett, in fact, believes such a phenomenon is occurring at 
present: 

Things are moving in the direction of design programs like 
CMU's [Carnegie Mellon University]. In terms of leading 
development efforts, the cognitive people are really taking 
charge. (Parlett, 1989, interview) 

There are a number of reasons for the preeminence of cognitive 
theory within the research design model. The connection be- 
tween the two has developed as a result of the longstanding 
relationship between computers and cognitive science, and the 
impact of cognitive science on composition theory. 

Cognition, Computers, and Composition Studies 

Psychologists have attempted to write programs that model 
human cognitive processes for almost as long as computers have 
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existed. Such models, it was argued, would offer theoretical 
explanations for observed human behaviors. One example of 
such an attempt was Edward Feigenbaum's 1959 project in 
which a computer was programmed to model the processes by 
which humans can memorize a list of nonsense syllables (Wei- 
zenbaum, 1976, pp. 162-163). While a computer could be easily 
programmed to perform such a task, "simulation" programs like 
Feigenbaum's are not performance oriented per se. Instead, they 
try to reveal possible cognitive processes by successfully modeling 
them in a computer program, by doing the task as a human 
would, not as a computer could — the a priori assumption being 
that on a most fundamental structural level, both the human 
mind and the computer program process information in the 
form of effective procedures. Thus, if a computer can be made 
to perform some task in the same way a human might, then the 
computer program can be said to be a cognitive model of how 
humans perform that task. 

One of the most influential projects using computers to 
simulate human cognitive processes was Simon and Newell's 
General Problem Solver, an information-processing system that 
sought to model human problem-solving behavior. Positing 
writing behavior as a form of problem-solving, Flower and 
Hayes (1981) adopted much of Simon and Newell's information- 
processing model to develop a cognitive model of writing be- 
havior. Represented in graphic form, their cognitive model 
resembles a computer flow chart for an information processor; 
but of course, in this case, the information processor is the 
human brain (Flower & Hayes, 1981, p. 370). The connection 
is one straight out of Simon and Newell's work: "All humans 
are information processing systems" (Newell, Shaw, & Simon, 
1957, p. 64). Part of the appeal of Flower and Hayes's work, 
and some might say, part of the problem with it, is the clearly 
schematized representation of this otherwise difficult to under- 
stand activity we call writing. 

From an earlier discussion we know that computer program- 
ming requires a highly defined procedural map of the activity 
that is being programmed. That simple technological fact gives 
the cognitive basis for CAC program design a great deal of 
appeal. Within the discourse of computer programming, Flower 
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and Hayes's model could be understood and appropriated as an 
underlying structural foundation for building computer tools. 
No other theory of composition offers such a highly defined 
mapping of the writing process, and metaphors like Elbow's 
(1973) "growing" (p. 22) and "cooking" (p. 53), for example, 
are antithetical to the highly defined procedural outlines of 
computer programming. As Kemp says, "When you program an 
activity, even the simplest activity, you must be procedurally 
accurate" (Kemp, 1989, interview). Not only does the cognitive 
approach to writing lend itself to CAC programming efforts, but 
it was making itself most strongly felt at the same time that the 
first flood of microcomputers was arriving on college campuses. 
Given their currency at the time, and their complementary and 
longstanding relationship, cognitive theories of writing and com- 
puter-aided composition came together in the research setting. 

Since then, and for reasons cited in my discussion of design 
models, the best-funded and best-rewarded CAC projects have 
been the cognitive-based research programs, those programs 
which have closely followed the theories of cognitive psychology. 
Woodruff is working under the auspices of Bereiter and Scar- 
damalia, Neuwirth acknowledges the strong influence of Flower 
and Hayes, and Smith has based WE on a synthesis of cognitive 
models that includes Flower and Hayes's, Bereiter and Scarda- 
malia's, and others. Indeed, Smith's opening statement in Smith 
and Lansman's "A Cognitive Basis for a Computer Writing 
Environment" (1987) neatly resolves the question of competing 
theories: 

During the past ten years, our understanding of writing has 
changed significantly. It was in 1980 that Dick Hayes and 
Linda Flower first outlined what has since become a standard 
model for both composition theorists as well as cognitive 
psychologists who study writing, (p. 1) 

Obviously Smith overstates the case, and he admitted as much 
in his interview, but he does hold a firm conviction that the 
cognitive approach is the right one and that CAC design confirms 
it and will drive that conviction for the rest of the field. 

This was made most clear in his keynote address at the 1989 
Computers and Writing Conference, where Smith echoed North's 
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critique of composition's claim to being a viable discipline. Like 
North, he argued that a lack of methodological soundness and 
an unfocused and centrifugal body of research have characterized 
composition; that to survive as a discipline, composition required 
a more clearly delineated research agenda, methodology, and 
practice; and that all three existed in the development of cog- 
nitively based computer tools such as WE, Smith (Smith & 
Lansman, 1987) criticizes those kinds of "little programs," as 
Woodruff calls them, which are typical of the other three design 
models and that are designed to address only part of the writing 
process, programs such as Prewrite and Organize: 

While these programs offer writers new tools, they do so 
piecemeal and with minimum concern for the large-scale 
structure of the writing task. Their designs often seem driven 
more by what the computer can be easily programmed to 
do, rather than by what will help writers most. (p. 1) 

He argues that CAC developers must design programs around 
the inherent cognitive processes that constitute the activity of 
writing: 

Badly needed are tools designed from the outset to closely 
match and to augment the inherent cognitive processes 
human beings use to perform the complex, multifaceted 
task of writing. The nature of the interaction between tool 
and tool user for computer writing invites, perhaps demands, 
a reconciliation between cognitive research and system 
design, (p. 1) 

Arguable in this passage is Smith's assumption that we can 
discuss an "inherent" and thus universal set of cognitive pro- 
cesses and his assumption that cognitive methodologies will do 
more than model them — indeed, that cognitive research can 
positively identify them. However, it is more useful here to note 
that in Smith's view, the paradigm shift is complete with our 
adherence to a cognitive approach and methodology, a theoretical 
stance that by nature precludes the diversity of approaches 
advocated in the earlier quoted passage from Bereiter and 
Scardamalia. 

Smith's attempts to capture and address the large-scale struc- 
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ture of the writing process have driven the concept of a "writing 
environment." WE, which stands for "writing environment," is 
based on a closed model — a multimodal cognitive model that 
accounts for every aspect that Smith and his associates identify 
as taking place in the writing process. The program's hypertext 
capabilities allow for recursive movement through each of the 
program's modes. Therefore to allow for the inclusion of a 
program like Prewrite would be to disrupt the unity of the model 
and the very structure of the program. Besides, Smith's conviction 
that his model of writing is closer to "right" than the models 
suggested in noncognitive approaches to composition makes the 
inclusion of these other approaches or subprograms not only 
unnecessary but theoretically unsound. Unlike the "macropro- 
grams" that reflect the current diversity of approaches in com- 
position theory writing environment programs like WE rigidly 
adhere to a single approach. If these programs go on to become 
preeminent in the field, their rigidity effectively devalues the 
approaches they reject. 

The Influence of Cognitive-Based CAC Programs 

Indeed, the software that emerges from the research design 
team model stands to exert great influence on the shape of other 
CAC programs, creating a ripple effect down the design contin- 
uum. This is so because, by nature, their design efforts are most 
advanced in terms of technological sophistication and capability. 
They therefore effectively set an agenda for the use of these 
technologies as they later become available to developers with 
more modest resources. Neuwirth has seen that dynamic with 
Notes, Comments, and ANDREW, the Carnegie Mellon-wide area 
network system upon which the program ran: 

ANDREW is now being used at several places and it has 
had a tremendous impact in the computer science world. 
For instance, it's the Open Software Foundation file system 
they chose, and things like that. (Neuwirth, 1991, interview) 

She imagines her group's research as creating a sound basis for 
the commercial software development of others. She says: 

IPO 
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Our model is sort of like . . . well you know, the first 
outliners were built in computer science, and they eventually 
made it to the marketplace years later, where, now, most 
word processors have some sort of outlining capability. 
That's the sort of influence we'd like to have, where someone 
reads about our work in a journal, and they're building 
stuff, and they're a commercial outfit, and they would say, 
"Yeah, let's try this!" (Neuwirth, ibid) 

This "trickle down" relationship with industry, which draws 
upon research from product design, gives the research team's 
findings a kind of product validity beyond its own theoretical 
soundness. Certainly, as writing lab directors search for good 
CAC programs, they will be drawn to these programs as the 
most technologically sophisticated, as the most tested, and as 
the ones endorsed by the corporate computer sector. 

This is an unsettling eventuality for some of the interviewees. 
It should be noted that most of the interview subjects expressing 
such anxieties were reluctant either to discuss or to elaborate on 
them. As with the aforementioned subject of defense funding, 
the nature of the CAC community made those interviewed 
hesitant to level criticism at any predominance by the research 
design teams. That said, Kemp worries about the impact of 
programs developed by research design teams. 

We need computer-based research facilities in English de- 
partments — not in every department, perhaps — but I see 
these things [CAC development projects] being relegated to 
Carnegie Mellon and Rensselaer and Michigan Tech. I don't 
think it's right for English departments to assume Carnegie 
Mellon is going to be able to work for them because, for 
all the respect I have for Carnegie Mellon and the New 
York Institute of Technology and Michigan Tech, they are 
still operating, I think, under certain kinds of assumptions, 
and we have slightly different assumptions. (Kemp, 1991, 
interview) 

Another researcher (who wished to remain anonymous) echoes 
Kemp's anxieties about cognitive-based CAC programs domi- 
nating the software market: 

A research institute like Carnegie Mellon has a limited vision 
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that I don't want to see limiting software. If their research 
is any indication of what their software is going to be, I 
don't want to see it entering ... I don't want to see it being 
the only vision. 

Helen Schwartz, who was a Dana Fellow at Carnegie Mellon, 
expresses unbounded admiration for the work of Neuwirth and 
her colleagues (as did virtually all of those interviewed). How- 
ever, she expresses fear that the software emerging from research 
design teams will too narrowly define the writing process for 
students and teachers: 

If I'm afraid of anything, it's that the software will only 
come out of Carnegie Mellon or Stanford, because I think 
there are other models [of the writing process] and that, at 
the very least, people have to be able to modify software 
for their students and their classrooms. (H. Schwartz, 1992, 
interview) 

Schwartz encourages software development within a variety of 
approaches to writing because of the way that software programs 
can inform and shape each other: 

Carnegie Mellon students are a particular type of student, 
and they're wonderful, but as some have argued, if we in 
academe don't create our own software, then we will be 
stuck modifying software designed for the business world. 
So the same argument applies: in our own world, we need 
more than one orientation, and we shouldn't rely on mod- 
ifying the software created at a Carnegie Mellon. Chris 
Neuwirth is the best. She knows programming and she 
knows rhetoric, but she has a particular orientation — I mean, 
she can't do all things. (H. Schwartz, ibid) 

Research design teams should not be blamed for their success 
in software design. The anxiety expressed by many was not that 
cognitive approaches were somehow wrong, but that conditions 
existed which discouraged software design by faculty with other 
theoretical approaches to composition. 

Diversity in Cognitive Approaches 

If Smith's solution to the diverse nature of composition 
research is to hold higher the banner of cognition, there are 
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other cognitive research design teams that seem more open to 
integrating other theoretical and pedagogical approaches. Wood- 
ruff's sounds like a social epistemic when he describes the 
benefits of CSILE's shared database of user notes: 

So the idea of authorship can slip away, or has to slip away. 
You can get credit for an idea if you want it, but the real 
power of the system is that everyone is trying to build, and 
you're part of a community of knowledge builders. (Wood- 
ruff, 1989, interview) 

Schwartz asserts that the Carnegie Mellon researchers are more 
open to diverse theory than they are given credit for. Indeed, 
at the 1989 Computers and Writing Conference, researchers 
from Carnegie Mellon offered presentations such as "Design 
and Implementation of a Computer-Supported Collaborative 
Writing Curriculum," "Creating the Dialogue: Using the Network 
to Initiate Collaborative Learning and Writing" and "Extending 
the Dialogue: Using the Network to Evaluate and Support 
Student Writing" These program developers, all working within 
a cognitive research model, were at least starting to explore 
sotial-epistemic concerns and to act upon them in their program 
design. 

Returning to Smith's WE program for a moment, it is interesting 
to note that he, too, acknowledges in the technical reports a 
"situational analysis" mode as one of the principle modes in his 
cognitive model. However, it is the one primary mode not included 
in the design of WE, leaving it for the writing instructor to 
address separately in class (Smith & Lansman, 1987, p. 16). He 
does point out that he has collaborated with Catherine Smith 
on three heuristic procedures for evaluating rhetorical concerns, 
and that they may, in the future, "be combined as a mode and 
included in the program design to address extrinsic concerns" 
(p. 16). The last phrase belies a social theory seen through the 
lens of cognitive research. 

WE's limitations aside, it is interesting to speculate on what 
seems to be an opening up of cognitive-based programs to the 
area of social epistemology. Selfe believes it is a matter of 
researchers responding to current thinking in the field: 
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I think those people are responding to an interest. What 
drives the profession if; that the profession comes up with 
interesting topics that it buys into for a year or two, or 
three or four, or maybe a decade, and this constructs the 
thinking of the members of the profession. And because 
we are intelligent human beings, we transport that to our 
work. (Selfe, 1989a, interview) 

Selfe's explanation points to another phenomenon that may 
help explain this widening perspective of the cognitive research 
developers. If a shift in the field can effect a rethinking of 
computer tools, then certainly a shift in technology has the same 
potential. Simply, the technology necessary to program a social- 
epistemic approach — the networking capability and the pro- 
cessing speed and memory required to drive il — has only recently 
become affordable for computer-based waiting labs. In addition, 
technological developments like hypertext are underscoring post- 
structuralist notions of intertextuality, giving that theory a kind 
of technological validity and a place in development efforts. 
Linking computers through networks, or telecommunications, 
presents a substantial expansion of the market for producers of 
the appropriate hardware and software. These are often the 
same corporate funding agents for the research design projects. 
As Woodruff pointed out, these corporate sponsors want to see 
software that will sell their product (Woodruff, 1989, interview). 
Therefore, we have a theoretical basis, a market basis, and the 
funding pressures for the integration of social-epistemic com- 
ponents in the research model. 

In a phenomenon quite the opposite of Smith's insistence on 
a solely cognitive model for writing, there are indications among 
some of the interview subjects that the boundaries between 
theoretical approaches are breaking down in CAC programs. 
When asked if he felt this were so, Woodruff responded: 

I think so. I think I would use different categories [than 
cognitive and social-epistemic]. For example, I might want 
to know if you are trying to be reflective with ideas at one 
time, or whether you are trying to expand them. [Here 
Woodruff is referring back to the activity of accessing the 
community database.] I'm not even string what those tasks 
are. I'm stating that I think we don't have a very good 
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understanding of that at all. And neither one of those fits 
comfortably. I think investigating networked environments 
will probably tell us more about that. (Woodruff, 1989, 
interview) 

While none of the subjects could describe concretely how the 
reconciliation of generally exclusive theories might be made 
operational in a program, those who commented felt that de- 
velopments in hypertext and a better understanding of the 
dynamics behind networked collaboration would help shed some 
light on the possibility of such a reconciliation taking place. In 
all cases, it was clear that the subjects were not positing a 
''maaroprogram'' of the sort Rodrigues and Rodrigues (1984) 
describe (p. 85), but rather a theoretical synthesis of traditionally 
competing theories of writing. That synthesis of theory may be 
more a hope than a reality in current CAC programs, but the 
desire to at least reconcile theories of context and cognition are 
powerfully voiced by Linda Flower (1989) for the field of 
composition in general: 

We need, I believe, a far more integrated theoretical vision 
which can explain how context cues cognition, which in its 
turn mediates and interprets the particular world that context 
provides, (p. 282) 

Because such a synthesis of theory for CAC development would 
have to find application in a program capable of handling a 
broad base of concerns, the writing environment programs being 
developed by research design teams would seem to best lend 
themselves to embodying a new hybrid theory of composition. 
However, it remains to be seen, whether a synthesis would, in 
fact, represent an integration of theories or a co-opting of one 
by another 

Giving Shape to the Future: 
Some Reflections 

English faculty conduct research, design curricula, and write 
textbooks, and those activities largely define our understanding 
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of written communication. In an age of electronic literacy, the 
software we and our students use will be a significant part of 
our pedagogy and may or may not embody a theory or ideology 
to our liking; thus we have an important stake in its development 
and design. English teachers in the virtual age must have a 
variety of quality CAC software programs from which to choose, 
a variety that reflects the full range of theory and pedagogy 
within composition studies. In the more distant future, as writing 
classes take place not within the physical confines of a classroom 
but in electronic or "virtual spaces/' software will more wholly 
define the characteristics of that writing space (Bolter, 1991; 
Moran, 1992). Peter Elbow's What Is English? (1990)— his re- 
flections on the 1987 English Coalition Conference — offers plu- 
ralism of theory and approach as one of the few certain answers 
to the title's question (p. 117). As the accounts in the present 
study reveal, that pluralism is at risk within the field of CAC 
software development. Commenting on the lack of good edu- 
cational software, Stephen Jobs, co-founder of Apple Computers 
and NeXt Computers, calls for faculty leadership: "Faculty are 
the experts. They are the people driving the educational expe- 
rience, and it's going to have to come from them" (Sprecher, 
1988, p. 128). In composition studies, that leadership, once 
energetic and widespread, is almost nonexistent due to the 
combination of factors examined in chapter 4. 

It would be unfair to underestimate the power and ability of 
teachers to make use of software, any software, in the best 
possible ways. Yet, imagine how much richer their classrooms 
might be if they had the means and support to create their own 
software, to answer the problems they see in their classes in the 
ways they know best. Ron Fortune agrees: 

It's extremely important that software applications respond 
to defined problems and needs, so that someone can say 
"Well, this software will help me do something or get at 
something in ways I can't otherwise do effectively." That's 
why the people who teach the courses have to develop 
software. Because if they're the ones articulating the prob- 
lems, it's difficult for someone out there to develop the right 
software for them. That's why I started using hypertext. 
(Fortune, 1991, interview) 
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In the traditional writing class, teachers fine-tune their pedagogy 
and materials to suit the particular problems or challenges of a 
class or an individual student. That may mean using some parts 
of a text and skipping other parts, copying handouts, renting 
film, and a host of other ways teachers exert control over the 
media of their pedagogy. Software, however, does not lend itself 
so well to such tampering, particularly if the designer leaves out 
the mechanisms for teacher control that Schwartz and Wresch, 
for example, include in their programs. 

Many with whom I spoke were pessimistic about the chances 
for any revival of widespread faculty development of software 
and for good reason. Despite technological developments that 
will allow even nonprogrammers to create complex software, 
departments and institutions continue to undervalue those ef- 
forts, funding is still difficult to acquire, and obstacles remain 
to effective dissemination of finished products. In developing an 
understanding of electronic literacy — supporting computer and 
writing work, in general, and software development, specifically, 
and training writing teachers for the new literacy as well as 
supplying them with the appropriate technology — composition 
studies is not keeping pace with the computer's growing adoption 
as the communication technology of choice for the workplace 
and the classroom. This is the context in which faculty find 
themselves. The accounts gathered for this book capture, in 
large part, the state of faculty-based software development at 
the end of the 1980s and beginning of the 1990s, but as Stephen 
Doheny-Farina and Lee Odell (1985) remind us, "No matter 
how carefully and thoroughly the ethnographer studies the life 
of a particular group, the details of that life will continue to 
change" (p. 530). There is much that can be done to revive and 
nurture faculty-developed software, and some of that ground- 
work is being established at present. 

While no single, concerted effort is being made to address 
the aforementioned problems facing faculty software developers 
(and there may be few who recognize the issue), a number of 
developments are encouraging. On one level, there is a growing 
acceptance of computers and writing studies and its importance 
within the discipline of composition studies. This is evidenced 
in Lunsford's presentation and the other instances mentioned 
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at the start of this chapter In addition, the language of computers 
and writing studies is coming into the lexicon of composition 
studies. For example, the forthcoming NCTE-sponsored Ency- 
clopedia of English Studies and Language Arts has a technology 
section and a full range of entries, and the new CCCC Bibliography 
of Composition and Rhetoric includes a section on computers and 
writing. It will become increasingly difficult for composition 
theorists to ignore computer-based writing in their work, partic- 
ularly as the sites for their research become electronic writing 
environments. 

On another level, the field of computers and writing is 
maturing. While much of the early research was more enthu- 
siastic than sound, much of the recent work has been original, 
rigorous, and has contributed to a widening understanding of 
computer-based writing. As a result, the subject has begun to 
receive more attention ir mainstream journals such as College 
English and College Composition and Communication, While there 
have been brief periods of heightened attention paid to com- 
puters and writing in the past, the current revival of attention 
is more likely to be sustained as many of the leaders within 
CAC studies come to play more prominent roles in composition 
studies in general. One recent example is Cindy Selfe and Gail 
Hawisher, editors of Computers and Composition and the series 
which is copublisher of this book, being named editors of the 
new CCCC Bibliography Recent attempts to address software 
issues have included a special issue of Computers and Composition, 
a revised version of the NCTE Software Evaluation Form, and 
new bibliographies of software and software-related texts. 

Perhaps the biggest change in the thinking about software 
development will be heralded by the development of hypermedia 
and its accompanying authoring systems; they present a powerful 
combination of intriguing pedagogical and theoretical possibilities 
combined with relative ease in use. As the authoring systems 
become even easier to use and as the platforms they require 
become less expensive, many faculty are likely to develop 
software even without improvements in institutional support or 
rewards. In that belief, I share Robert Alun Jones's (1988) sense 
of the immediate present and not too distant future: 
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In twenty years, when historians of technology write the 
chapter on hypermedia in higher education, they will most 
likely focus on two, seemingly inexplicable phenomena. The 
first will have been the initial reluctance of the vast majority 
of the professoriate, despite the availability and future 
promise of enormously powerful tools, to become even the 
least bit involved. The second will have been the way in 
which this inertia was broken through, (p. 44) 

That breakthrough may occur in the area of English studies. 
Because knowledge making and meaning making are at the 
heart of English studies, hypermedia, with its radical redefinition 
of those processes, stands to impact English studies perhaps 
more than any other discipline in the academy. As that occurs, 
the ability to navigate electronic writing spaces, to use Bolter's 
(1991) term, will become transparent to functioning within the 
field. At that point, computers and writing merges with com- 
position and disappears as a separate area of research and study 
At that point, developing software becomes as common to writing 
instruction as the current preparation of traditional print class- 
room materials. 

Revolutionary technologies are only revolutionary when they 
touch one's life. The "Age of Steam" meant nothing to an 
English farmer in some remote Yorkshire village until the day 
the railroad arrived and nothing was again the same. The English 
historian, E.J. Hobsbawm (1982), explains: 

It [the railroad] transformed the speed of movement — indeed 
of human life — from one measured in single miles per hour, 
and introduced the notion of a gigantic, nation-wide, com- 
plex and exact interlocking routine symbolized by the rail- 
way time-table (from which all subsequent "time-tables" 
took their name and inspiration). It revealed the possibilities 
of technical progress as nothing else had done, because it 
was both more advanced than most other forms of technical 
activity and omnipresent, (p. 110) 

Like the Yorkshire farmer, anyone who writes cannot help but 
be touched by the new electronic technology, and when that 
becomes pervasive, the study and teaching of writing will be 
irrevocably changed. However, unlike the brute presence of 
industrial steel and steam, computer technology relies on the 
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diminution of its physical presence and is mostly experienced 
through software, which is created through intellectual endeavor 
and imagination, the currency of academic life. Therefore, those 
of us who write, teach, and theorize about writing have a rare 
opportunity to play a part in our own destiny, to help shape 
the revolution. 
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The following is a list of software programs mentioned in this book. 
The list provides a brief description of each program and, in some 
cases, a sample of the program interface. 

Comments is a network-based writing response program (fig.l). Writers 
can send a draft to a reader for response or a reader can request the 
draft of a writer. The program allows users to identify a section of 
text and append to it a comment. In addition, comments can be 
appended to comments, allowing multiple readers to offer input on a 
document. The networked nature of the program allows the writer to 
ask for clarification of comments and to establish a dialogue with 
readers. 

CSILE (Computer-Supported Intentional Learning Environment) is a 
networked system that gives students simultaneous access to a database 



Directions 

Open the menus ind choose one of the following from the Options men 
cird: r 

Send i Piper — to send i piper. 

Request i Piper's Return - to request the return of a piper you hive 
afreidy sent r r ' 

Reid i Piper - to reid or make comments on i piper. 

Delete Comments - to remove afl comments from i piper. 

Help ~ to cid up the program's online help. 

Report i Program Problem - to report i problem with the program. 
Quit — to quit the Comments program. 



Figure 1. The Comments program options. (Used by permission of the 
developer, Christine Neuwirth.) 
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Thinking 
type: 



Write 1/2 ^ info spell copy cut paste form 



Problem 

Why wore the Nraderthals so truch mere muscular 
than us? Hew come if devn the line we have ha'1 
out brains grow but than the Neanderthal cw and 
it's head was 1/4 bigger than ours wh> ? Did we 
keep scne of the genes fien the Neaderthal? 



V 



I 



a 



si 



Read 2/s -*- Info 



Neanderthals anatomical features 
Neanderthals were very modern and advanced ev*n 
more advanced than us. The neanderthals had a very 
big head and a very big brain. Their brain was 
bigger than ours! The average brain site in neander- 
thals was around ISOOcc's They had a biq forehead 
that was long and lew there skul was flat cn the tcp 
and they had very big eye brow ridges. There 
nostrils were very big and they had a wide face. 
Their bones wore heavy and they had strong liqaments. 
Their cheek bones stuck out. 

The women had biq pelvic areas some say that 
was because for the babys head to come out the> need 
a biq open space bigqer that ours because their heads 
are bigger than our*; is. 



Figure 2. CSILE screen showing read-a-note and write-a-note win- 
dows. Hie arrows in a read-a-note window (top) permit 
stepping through a set of notes retrieved through a 
pseudonatural language Boolean search. The arrows on a 
write-a-note window (bottom) permit stepping through a set 
of notes in process. (Used by permission of the developer, Earl 
Woodruff,) 





i 






4J 




















CO 








c 


o 


— 
















•H 












*l J 








CD 










03 












co 








C 


co 




c 






CD 








o 


-H • 




■H 






>l 




H 




CO 
M 


CD 

4J > 




co 




o 


CD 


a 




CD 


M 03 




4-1 -H 




CD 


^-i 








Ol. 


X! 




o 

CD 




•n 


Z3 
O 




^ 




X! 


• D 




CD C 




o 


>i 




U 






co O 




4J O 




CO 






O 




-H 


CD >i 




03 






co 




H 






O 




4J CD 




03 


c 












co co 






a) 








co 


03 








4-1 


a 








CD 


cd x: 




03 03 




o 


• o 




CO 




•H 






U 










0) 




M 


o 




x: CD 






co .u> 


rH 




03 


>i c 








c 


O 05 




H 




> 


u o 








03 


5-1 x: 








(D -H 








5h 










CD 


> 4J 








O 










& 


CD Cu 




O cj» 




C 


C CJ> 


CD 






CD 








CT> 


03 C 




CP 




CD 


4J O 








-<H 


O H 


03 




rH 


03 U 




o x; h 






x: 


co 






X! CD 




4-> 4-> D 




CP 4J 


CD ±J 


co 




o 


4J Oa 




CD 4H 




c o 


rH CD 


<u 




c o 






CD £ 




•H CD 


a e 




5 






C CD 

03 rC 




M O "H 

O CO CD 




CD *rn 
XI XI 


o o 

CD CO 


rH 






CD 




£ o 






a 






03 C 






CT> CD 




±j co 


u 


u 










CD C T> 




o 


4J o 








4J f— 1 


±J o 








C 4J 


03 


03 




f-H 


o 




03 M O 




03 


x: - 


a 




>i-H 


c c 




x: *h co 




co x: 


4J CD 








03 5 


o 




CO H 




•H 


4H 








CO 


CO -H 




X: CD 03 








CD 




g 


CD 4J 








rH C 


C rH 


cr> 




3 03 


O *H 




3 CD 




CD O 


-H 


03 




O 


T> C 


>i 


u 4h x: 




CD 


XT rH 


co 




>i M 


-H 


03 


4J O 


Cr» ^ TJ 


U 03 


co 






CD <H 




co 


c 


C 


CD CD 


CD 




C 


3 CD 


O 


U CD -H 


-H 


i — i o3 


g u 


g 




03 0» 




rH 




rH 


a o 








O C 




rH 


C 03 rH 


a 




co co 






o 


co 


0? 


co u p 


*«H 


CD CD 


•H 


C 






CO CD 


O 


CD CO 4-/ 




CP 




CD 




O 4J 


03 *H 




o x: 




-u o 


*H >i 






ac a 


±J 


-H 


T> 03 ±J 




CD ±J 










0) 


^ 0 


4J 


P 


CD 


rH 


JC -H 






c 


o 


U -H 


CO 


C C >H 


Jh 


5 CD 


U rH 






x: 


u 


O U 


-H 


x: o3 4J 




O rH 


n 03 






o 


CD 

a 


H O 

XI CO 




o x; c 

b 4J P 


c 


C X) 

« m 


M CD 

H a: 










< 



-3 ill 

<p (0 2 w 
w d D . 

sin 

Ha 8 

I J! ^ 
a, 



r w ^ . 

s ^ 

a, o ^ 
'0 ^ 

Ells 

J O 
Xi 

CD 



y S 8 



g S u 



■a o 

S ,J 

to » 

23 > 



^ Si «(5 

g 0) 
O (jo 



- o 



5 a, 

S -9 



IS! 



U4 V 

oj W) e « 2 
CO C ^ -5 



CO C ^ -5 

6 S' 



« (u S 

fflHi 

6 S fS ^ 



CO 
0) 



156 



Appendix 



Hayes, J.R. (1982). What is a creative act?. The Complete Problem Sober 
(pp. 197 - 198). Philadelphia: ' c ranWin Institute Press. 

Consequential 
Length of time 
Copy cats 
Ongmality criterion 
Newness 

Value vs Consequential 
Subjectivity and value 7 
Being there 
Housepamter example 
Intentionality 



Perkins, D. N. (1981). Having It. "he Mind's Best Wort Cambridge, MA 
Harvard University Press. 

Memory 
More creative 

Criteria for postulating an ability, 




Figure 4. The Notes program window. (Used by permission of the 
developer, Christine Neuwirth.) 



that is composed of text and graphical notes which the students 
produce themselves. The system provides students a means of searching 
and commenting on one another's contributions (fig. 2). 

Interchange is a real-time or synchronous conferencing program that 
allows simultaneous text-based discussion in a networked computer 
classroom (fig. 3). The program allows on-line discussion, subconfer- 
ences, and group analysis of text through a "View-a-File" function. 
Interchange is part of the Daedalus Ins. actional System, a set of 
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integrated programs that include invention e-mail, word processing, 
and revision, but each can be purchased separately. 

Mindwriter is the invention program within the Daedalus Instructional 
System, though it can be purchased separately. The program is based 
on Hugh Burns's 1977 invention programs TOPOl, TAG1, and BURKE. 
Mindwriter offers three sets of prompts that are designed to help 
students explore a topic. As in Burns's TOPOl program, the prompt 
sets are based on Aristotle's topoi, Young, Becker, and Pike's tagmemics, 
and Burke's pentad. 

Notes allows readers to make notes on on-liiic source texts and to 
make direct links between the source text and the electronically stored 
notes. The program maintains a list of all notes taken, and the user 
can then view selected notes, classify them, and organize them in 
various ways (fig. 4). 

Organize is a prewriting program composed of modules for prewriting 
that include a large number of tutorials on development, generating 
ideas, audience assessment, creating an argument for debate, and 
approaches to drafting. 

Prep Editor ("Work in Preparation") is a network-based program that 
supports collaborative writing, particularly through its co-authoring 
and commenting functions. The hypermedia capability of the program 
allows spatial representations of ideas and their restructuring. Authors 
can define "drafts," areas of that writing space which an author opens 
up to others for their collaboration and comments. The interface allows 
multiple on-screen "columns" that contain different types of infor- 
mation. For example, a set of columns might hold a draft, the larger 
outline into which it fits, and a reader's comments on that draft. 

Prewrite is an invention program that prompts the user in brainstorm- 
ing an expository essay or autobiographical/fictional work (fig. 5). The 
program prompvs for information on topic, purpose, key ideas, audi- 
ence, metaphor, and other components of the writing process. The 
answers can then be printed as a set of notes to be used in the first 
stago of the writing process. Instructors can modify the prompts. 

Prose is an instructor feedback program that allows the user to respond 
within the student text with pre-programmed comments on mechanical 
errors (with built-in tutorials), the writer's own comments on any part 
of the text, or overall summary comments. Prose flags the text so that 
the responses are linked directly to the passage in question. In addition, 
the program allows the instructor to guide the revision by forcing the 
student to address the revisions in a given order. 

SEEN offers six tutorials for examining or exploring a particular subject. 
The tutorials focus on character analysis, exploratory essays, art ex- 
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Hi, what's your name? 

Sandi Mackey 

Any Ideas on what to write? Y or N. 

Yes, I want to write about soap operas and 
why so many people get hooked on them. 

Okay. Now give me a one-to-five word title for 
your topic. Here are some examples: Feeling 
Blue, Are Schoolya ;ds Safe?, Flying Saucers. 
What's your title? 

Hooked on Soaps 

What made you choose "Hooked on Soaps" 
to write about? 

Because every afternoon the Student Center 
is filled with busy people watching General 
Hospital. And that includes me — even if I 
have a midterm and paper due the next day. 
Why do i do it? What's the lure? ; . . 



Figure 5. Excerpt from Prewrite questions. In Prewrite, a series of inter- 
active questions and answers results in a printout of the 
writer's thoughts, which can be used as notes for developing 
a first draft. (Used by permission of the designer, Mimi 
Schwartz.) 

ploration, historical conflicts, essay analysis, and plotting in literature. 
The tutorials can be customized by the instructor. The program also 
includes bulletin boards that allow for asynchronous collaboration 
among student writers. 

Thoughtline was originally designed for business users who wanted 
help in the preparation of presentations or reports. It is an invention 
program that uses Artificial Intelligence (AI) features to prompt the 
user for information and then to refine or expand on that information. 
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The program creates an open-ended, nondirective dialogue with the 
user in the same manner of Joseph Weizenbaum's now famous ELIZA 
program. 

WE is a hypertext "writing environment" program designed for a 
networked environment. Based on an explicit cognitive model of the 
writing process, WE operates within six distinct modes that can each 
operate in a separate window on screen. The user can quickly and 
easily move from one mode to another and manipulate screen objects 
which directly affect the text linked to those objects (in reorganizing 
the structure of an essay, for example). 

Writer's Helper is a macro-environment program that offers a wide 
range of instructional modules or activities. These include nineteen 
prewriting activities that address discovery, invention, and organization, 
and twenty revising modules that address structure, audience, and 
style. The new Windows version of Writer's Helper includes more tools 
than the previous version and smoother integration with word-pro- 
cessing programs. 
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